Kort om det viktigaste: Clean Architecture, Robert C. Martin

Detta kommer att vara en berättelse om mina intryck av boken, och några begrepp och kunskaper som har lärt sig tack vare den.

Arkitektur

Kan du, när du läser den här publikationen, ge ett klart svar på frågan, vad är arkitektur? Vad är arkitektur i sammanhanget av programmering och design? Vilken roll spelar den? Det finns ganska många oklarheter kring denna term. Det verkar som att allt är förståeligt, men på något sätt abstrakt och utan precision. Martin anser, och jag instämmer med honom, att en applikation har två komponenter:

1. Beteende (behavior) – de funktioner och uppgifter som programmet (komponenten, tjänsten) utför.
2. Arkitektur – denna term handlar i hög grad om att förändra applikationen.

Men även om applikationen mycket väl utför den uppgift den ska, betyder det inte att den har en bra arkitektur. Arkitektur handlar inte om en applikations beteende. Arkitektur handlar om enkelheten i att förändras, arkitektur handlar om enkelheten i att distribueras, arkitektur handlar om oberoende utveckling. Arkitektur handlar om hastigheten med vilken en ny person i teamet förstår.

Och hur man bygger denna arkitektur, hur man slipper huvudvärken vid små förändringar av krav från PM:en, eller från intressenten: det är vad boken kommer att berätta om.

Om författarna

Innan jag pratar mer om denna bok, vill jag säga lite om mig själv.
Just nu är jag en Strong Junior Developer, som specialiserar sig på att utveckla tjänster med ASP .NET CORE.

Jag har arbetat på en "galleri" i ett år, och verkar så smått klara av det.

Jag har redan läst denna bok två gånger, och jag rekommenderar läsning till alla:

• utvecklare av embedded system;
• frontend-utvecklare;
• backend-utvecklare;
• och till och med DevOps.

Kort sagt, till alla som på något sätt är involverade i mjukvaruutveckling, här menar jag direkt utveckling av olika saker, vi tar inte med PM:er här (även om det också skulle vara nyttigt att veta varför devs ibland lägger dubbelt så mycket tid på en uppgift), jag rekommenderar att läsa denna bok.
Och nu ska jag försöka argumentera för varför jag tycker så.

Lite om författaren till den här boken (eftersom författarens auktoritet spelar en stor roll för mig). Jag tror att du förstår mig, även om det inte alltid är korrekt, men när en auktoritativ person inom sitt område pratar — så ger det mycket mer förtroende för vad som sägs. Till exempel, jag tror att du har större tro på diagnosen som läkaren ger, än på någon okänd person från folkmassan (som har googlat symtom).

Robert Martin — även känd som Uncle Bob — har arbetat inom programmering, inklusive olika system (från webbtjänster till inbyggda system), sedan 1970-talet. Han är teknisk konsult och arkitekt, har skrivit för olika tekniska tidskrifter, och är i grunden en mycket erfaren programmerare, och en person som spelade en nyckelroll i skapandet av de välkända SOLID-principerna (man kan säga att han är skaparen). Jag vill också nämna att denna bok rekommenderades av min teamledare med över 15 års erfarenhet.

Om boken

Beroenden

Innan jag läste boken, hade jag läst en hel del artiklar på Habré där ordet "beroende" nämndes. Vad innebär det, vem beror på vem, vad betyder det konkret att "hänga på", och hur kan en klass bero på någon annan?

Och med tiden när jag läste boken insåg jag två punkter:

Beroende — är en term som innebär att en viss klass (komponent, tjänst) känner till en annan klass (komponent, tjänst), och denna kunskap definieras i koden (nu kommer Java- och C#-programmerare att förstå mig) genom ett visst namnrymdimport. Med andra ord: om du har klass A med namnrymden Default.Classes och klass B med Another.Classes. Så om det i källkoden för klass A står using Another.Classes; — betyder det att klass A är beroende av klass B.
För att förstå schemat, se på riktningen av pilen: i 1) kommer pilen att peka från klass A mot klass B. Det betyder att klass B är mer oberoende än klass A. Och förändringar i klass A kommer inte att orsaka något "skada" för klass B.

SOLID

En av de främsta anledningarna till att jag läste denna bok — är förklaringen av SOLID-principerna från första källan, eftersom farbror Rob utvecklade dessa principer och man kan säga att det är tack vare honom som vi hör detta namn — SOLID.
För dem som inte vet - dessa principer säger att man ska designa sina applikationer i enlighet med fem regler:

S — SRP (Principen om enkel ansvarighet)
O — OCP (Principen om öppen-stängdhet)
L — LSP (Liskovs substitutionsprincip)
I — ISP (Principen om gränssnittets segregations)
D — DIP (Principen om beroendeinversion)

Alla dessa principer kan tillämpas på nivåer av klasser och objekt, på nivåer av moduler och komponenter, och på nivåer av lager (tjänster).

Om du tycker att principen om enkel ansvarighet handlar om att en klass eller modul bara ska göra en enda sak - då måste du läsa åtminstone kapitlet om SOLID. För den definition som ges ovan är en konsekvens, och inget annat än själva definitionen av principen.

Om beroendeinversion

Jag vill särskilt påpeka förklaringen av principen om beroendeinversion (den som är D i SOLID). Under läsningen av boken insåg jag att det inte bara är en princip, utan också en mekanism och ett verktyg, med hjälp av vilket du kan ändra riktningen på dina beroenden och göra, till exempel, affärslogiken (DOMÄN) oberoende av detaljerna i implementeringen av datatillgångslagret (DAL).

Även om själva principen, tillsammans med de andra i SOLID, har en något annan innebörd än mekanismen, så används mekanismen genom hela boken, och det är en av de grundläggande metoderna för att invertera och ändra riktningen på dina beroenden, som för övrigt används i DDD.

Om beslut kring arkitektur

Mycket ofta nämner boken principen om att fatta viktiga arkitekturmässiga beslut: vilken databas man ska använda, vilket ramverk man ska använda, vilken bibliotek man ska koppla in, vilket man ska använda som sökmotor etc.

Så författaren anser: du ska FÖRSÖKA ATT MINIMERA dessa typer av beslut. Eftersom krav kan förändras, prestandabegränsningar kan också förändras, och den beteendemässiga komponenten har en tendens att förändras. Under utvecklingsprocessen kan ett beslut visa sig vara mindre effektivt än ett annat, mindre bekvämt än ett annat. Och kraften i din arkitektur kommer att avgöra hur snabbt och smärtfritt du kan byta en teknologi mot en annan (och detta bekräftar för övrigt OCP).

Till exempel, plötsligt bestämmer du dig för att använda MongoDB istället för PostgreSQL, eller överhuvudtaget filer, eller använda mockade data som operationerna körs i minnet. Och under vissa förhållanden - detta kan tvinga dig att skriva om nästan hela logiken.

För att undvika sådana situationer kan vi använda vissa mekanismer som förflyttar beslutstiden så långt bort som möjligt. En av dessa mekanismer är abstraktion.

Referenser till DDD

DDD – Domain Driven Design – är en metod för att utveckla tjänster med komplex affärslogik, kritisk för förändringar, som syftar till att maximera förståelsen hos projektets ledande roller (PMs, försäljningschefer etc.) samt de ordinarie medlemmarna. Det handlar om att alla medlemmar i projektet ska ha ett ubiquitous language, så att varje person kan förstå den andra och att alla tänker inom samma domän med samma affärsregler.

Om du är en anhängare av DDD, eller vill bli en, eller om du inte förstår det men vill förstå — är boken ett måste, särskilt den andra delen av boken.

Här förklarar författaren förekomsten av Dependency Rule, och varför, genom att följa den, kommer du att bygga en korrekt applikationsarkitektur. Varför beroenden bör följa riktningen mot High Policy-komponenterna, varför domänen (High Policy-komponent) bör vara oberoende av infrastrukturen och hur detta kommer att förenkla din distribution och utveckling.

Abstraktion

Farbror Rob berättar också om hur implementationsdetaljer kan skada ditt system och hindra det från att utvecklas utan smärta senare.

Kom ihåg!
DB är en implementationsdetalj
Kunder (Web, Mobile, etc) är implementationsdetaljer
Ramverk är implementationsdetaljer

Du bör maximalt abstrahera från allt detta och inte vara beroende, genom att använda den ovan beskrivna Dependency Inversion med gränssnitt och abstraktioner, Dependency Rule och andra mekanismer.

Metoder för moduluppbyggnad

Detta avsnitt gillade jag extra mycket som utvecklare av tjänster i ASP .NET CORE. Här diskuteras metodologier för att bygga en enhetlig arkitektur för tjänsten av färdiga komponenter.

Robert beskrev fyra möjliga scheman för uppdelning av lager.

Han påpekade varför den så ofta använda mekanismen för tre-lagersarkitektur: UI (controllers), Tjänster (Domain), DAL (Databas) – är ganska dålig jämfört med andra. Jag har inte sett så många projekt, men i varje exempelvis mikro-tjänst på backend används precis tre-lagersarkitekturen.

Också, används ofta en komponent-till-en-tjänst-arkitektur. Överlag är de båda ganska bra, men den har en hel del nackdelar i jämförelse med hur arkitekturen byggs vid användning av DDD, särskilt vid kritiska förändringar och komplexa tjänster.

Sammanfattningsvis har jag kommit till slutet av denna recension av boken. Jag tyckte verkligen om boken, jag ångrar inte att jag läste den, tack till författaren. Till er, kära läsare, tack för er uppmärksamhet, döm inte för hårt — detta inlägg är baserat på intrycket av boken och min personliga entusiasm.

Källa: habr.com