Dette vil være en historie om mine inntrykk av boken, og vil også diskutere noen av begrepene og kunnskapen som, takket være denne boken, ble lært
arkitektur
Kan du, ved å lese denne publikasjonen, gi et klart svar på spørsmålet, hva er arkitektur? Hva er arkitektur i sammenheng med programmering og design? Hvilken rolle spiller hun? Det er ganske mange uklarheter i dette begrepet. Og alt ser ut til å være klart, men på en eller annen måte abstrakt, og uten presisjon. Martin mener, og jeg er enig med ham, at søknaden har to komponenter:
- Atferd - funksjoner og oppgaver som et program (komponent, tjeneste) utfører.
- Arkitektur - dette begrepet handler mer om å endre applikasjonen.
Men selv om en applikasjon utfører oppgaven den skal utføre veldig bra, betyr ikke dette at den har en god arkitektur. Arkitektur handler ikke om applikasjonsatferd. Arkitektur handler om enkel endring, arkitektur handler om enkel distribusjon, arkitektur handler om uavhengighet av utvikling. Arkitektur handler om hastigheten som forståelsen kommer til en ny person på laget
Og her er hvordan du bygger denne arkitekturen, hvordan du blir kvitt hodepine når det er en liten endring i krav fra en PM eller fra en interessent: dette er hva boken vil fortelle deg om
Om forfattere
Før jeg sier noe om denne boken, vil jeg si litt om meg selv.
For øyeblikket er jeg en sterk juniorutvikler, som spesialiserer meg på utvikling av tjenester ved bruk av ASP .NET CORE.
Jeg har jobbet på det samme "galleriet" i et år nå, og det virker som jeg klarer meg litt
Jeg har allerede lest denne boken 2 ganger, og jeg anbefaler den til alle:
- utviklere av innebygde systemer;
- front-end ingeniører;
- back-end arbeidere;
- og til og med til devops.
Generelt, for alle som på noen måte er knyttet til utvikling av programvare, mener vi direkte utvikling av ulike salgs- og PM-er, vi tar ikke hensyn her (selv om det også ville være nyttig å vite hvorfor jenter noen ganger bruker 2 ganger mer tid på en oppgave), anbefaler jeg deg å lese denne boken.
Og nå skal jeg prøve å argumentere for hvorfor jeg tror det
Litt om forfatteren av denne boken (fordi for meg spiller forfatterens autoritet en stor rolle). Jeg tror du vil forstå meg, selv om dette ikke alltid er riktig, men hvis en autoritativ person i feltet forteller deg noe, viser du mye mer tillit til det han sa. For eksempel tror jeg du vil tro mer på diagnosen en lege gir deg enn fra en person fra mengden (som googlet symptomer)
Robert Martin - alias onkel Bob (onkel Bob) - har jobbet innen programmering og ulike systemer (fra webtjenester til innebygde systemer), siden 1970. er teknisk konsulent og arkitekt, har skrevet for ulike tekniske magasiner, er selv en meget erfaren programmerer, og en person som spilte en av nøkkelrollene i skapelsen av de velkjente SOLID-prinsippene (man kan si skaperen). Jeg vil også legge til at denne boken ble anbefalt til meg av teamlederen min med 15+ arbeidserfaring
Om boka
Avhengigheter
Før jeg leste boken leste jeg ganske mange artikler om Habré, der ordet "avhengighet" dukket opp. Hva er det, hvem er avhengig av hvem, hva betyr egentlig «avhengig», og hvordan kan en klasse være avhengig av noen?
Og mens jeg leste boken, lærte jeg to ting:
Avhengighet er et begrep som betyr at en eller annen klasse (komponent, tjeneste) vet om en annen klasse (komponent, tjeneste), og denne kunnskapen på kodenivå bestemmes (nå vil javaister, Sharpister, Sishniks forstå meg) av en viss navneområdeimport . Med andre ord: du har klasse A med navneområdet Default.Classes og klasse B Another.Classes. Så hvis kildekoden til klasse A inneholder bruk av Another.Classes; - dette betyr at klasse A er avhengig av klasse B.
For å forstå fra diagrammet hvor den avhengige klassen er og hvor den ikke er, se på pilens retning: i 1) vil pilen peke fra klasse A i retning av klasse B. Dette betyr at klasse B er mer uavhengig enn klasse A. Og endringer i klasse A vil ingen "skade" påføres klasse B
SOLID
En av hovedgrunnene til at jeg leste denne boken var forklaringen av SOLID-prinsippene fra den opprinnelige kilden, fordi onkel Rob utviklet disse prinsippene og, kan man si, takket være ham hører vi dette navnet - SOLID.
For de som ikke er i det, taler disse prinsippene og råder deg til å designe søknadene dine i samsvar med 5 regler:
S - SRP (enkelt ansvarsprinsipp)
O - OCP (Åpent-lukket prinsipp)
L - LSP (Liskov substitusjonsprinsipp)
I - ISP (grensesnittsegregeringsprinsipp)
D - DIP (Dependency Inversion Princip)
Alle disse prinsippene kan brukes på nivået av klasser og objekter, på nivået av moduler og komponenter, og på nivået av skinner (tjenester).
Hvis du mener at Single Responsibility-prinsippet betyr at en klasse eller modul bare skal gjøre én ting, så må du definitivt lese minst kapittelet om Solid. For definisjonen gitt ovenfor er en konsekvens, men ikke en definisjon av selve prinsippet
Om avhengighetsinversjon
Jeg vil gjerne være spesielt oppmerksom på forklaringen av avhengighetsinversjonsprinsippet (den ene D fra SOLID). Mens jeg leste boken innså jeg at dette ikke bare er et prinsipp, det er også en mekanisme og et verktøy som du kan bruke til å endre retningen på dine avhengigheter og gjøre for eksempel forretningslogikk (DOMAIN) uavhengig av detaljene i Implementering av datatilgangslag (DAL)
Selv om selve prinsippet, sammen med de andre i SOLID, betyr litt annerledes enn mekanismen, brukes selve mekanismen gjennom hele boken, og dette er en av hovedmetodene for å snu og endre retningen på dine avhengigheter, som, brukes forresten i DDD
Om å ta arkitektoniske avgjørelser
Svært ofte vil boken nevne prinsippet om å ta viktige arkitektoniske beslutninger: hvilken database som skal brukes, hvilket rammeverk som skal brukes, hvilket bibliotek som skal inkluderes, hva som skal brukes som søkemotor, etc.
Så, mener forfatteren: du bør ta slike beslutninger SÅ MINDRE SOM MULIG. Fordi krav kan endres, begrensninger på ytelse også, har selve atferdskomponenten en tendens til å endre seg. Under utviklingsprosessen kan en løsning virke mindre effektiv enn en annen, mindre praktisk enn en annen. Og styrken til arkitekturen din vil avgjøre hvor raskt og smertefritt du kan erstatte en teknologi med en annen (OCP snakker forresten om dette).
For eksempel, plutselig bestemmer du deg for å bruke MongoDb i stedet for Postgresql, eller filer generelt, eller bruke falske data, operasjoner som vil bli utført i minnet. Og under visse forhold kan dette tvinge deg til å omskrive nesten all logikken.
For å unngå at slike situasjoner oppstår, kan vi bruke noen mekanismer som vil presse beslutningstiden så langt som mulig. En av disse mekanismene er abstraksjon.
Lenker til DDD
DDD - Domain Driven Design - en tilnærming til å utvikle tjenester med kompleks forretningslogikk, kritisk for endringer, som er rettet mot å maksimere forståelsen av prosjektlederstillinger (PMer, Salgsledere etc), med vanlige roere. Altså slik at det skulle være et allestedsnærværende språk mellom alle medlemmene i prosjektet, og alle kunne forstå den andre, og slik at alle skulle tenke i samme domene med de samme forretningsreglene.
Hvis du er en DDD-tilhenger, eller ønsker å bli det, eller du ikke forstår noe om det, men ønsker å forstå det, er boken et must å lese, spesielt den andre delen av boken.
Her forklarer forfatteren eksistensen av avhengighetsregelen og hvorfor det å følge den vil hjelpe deg med å bygge riktig applikasjonsarkitektur. Hvorfor avhengigheter bør flyte mot komponenter med høy policy, og hvorfor domene (Høy policy-komponent) bør være infrastrukturuavhengig, og hvordan dette vil forenkle utrulling og utvikling
abstraksjon
Onkel Rob snakker også om hvordan implementeringsdetaljer kan skade systemet ditt og hindre det i å utvikle seg uten smerte i fremtiden.
Husk!
Databasen er en implementeringsdetalj
Klienter (nett, mobil osv.) - implementeringsdetaljer
Rammer er en implementeringsdetalj
Du må abstrahere så mye som mulig fra alt dette og ikke være avhengig av det, ved å bruke avhengighetsinversjonen beskrevet ovenfor med grensesnitt og abstraksjoner, avhengighetsregel og andre mekanismer
Metoder for å bygge moduler
Jeg likte spesielt denne delen som utvikler av tjenester på ASP .NET CORE. For her snakker vi om metoder for å bygge en enhetlig tjenestearkitektur fra ferdige komponenter.
Robert beskrev 4 mulige lagseparasjonsskjemaer.
Han gjorde det klart hvorfor den så ofte brukte mekanismen til 3-lags arkitektur: UI (kontrollere), Services (Domain), DAL (Database) er ganske dårlig sammenlignet med andre. Jeg har ikke sett så mange prosjekter, men hvert av dem, for eksempel en mikrotjeneste på baksiden, bruker en trelagsarkitektur.
Også ganske ofte brukes en-komponent-en-tjenestearkitekturen. Generelt er de begge ganske gode, men det har ganske mange ulemper, sammenlignet for eksempel med hvordan arkitekturen er bygget opp ved bruk av DDD, spesielt med kritiske tjenester og komplekse tjenester.
Uansett, dette er slutten på denne bokanmeldelsen. Jeg likte selve boken, jeg angrer ikke på å ha lest den, takket være forfatteren. Til dere, kjære lesere, takk for oppmerksomheten, ikke døm strengt - denne publikasjonen er basert på inntrykket av boken og min personlige entusiasme
Kilde: www.habr.com
