Lühidalt peamisest: Clean Architecture, Robert C. Martin

See on jutt raamatust, samuti käsitleme mõningaid mõisteid ja teadmisi, mida tänu sellele raamatule on omandatud.

Arhitektuur

Kas te suudate sellele postitusele lugedes selgelt vastata küsimusele, mis on arhitektuur? Mis on arhitektuur programmeerimise ja disaini kontekstis? Millist rolli see mängib? Selles mõttes on palju ebaselgust. Kõik tundub justkui selge, kuid siiski abstraktne ja täpsuseta. Martin ütleb, ja ma olen temaga ühel meelel, et rakendusel on kaks osa:

1. Käitumine (behavior) — funktsioonid ja ülesanded, mida programm (komponent, teenus) täidab.
2. Arhitektuur — see mõisted käsitleb rohkem rakenduse muutmist.

Kuid isegi kui rakendus täidab väga hästi ülesande, mille ta peab täitma, ei tähenda see, et tal on hea arhitektuur. Arhitektuur ei ole rakenduse käitumise kohta. Arhitektuur on seotud muudatuste lihtsusega, arhitektuur on seotud juurutamise lihtsusega, arhitektuur on seotud arendamise sõltumatusega. Arhitektuur on seotud sellega, kui kiiresti uus inimene meeskonnas mõistmisele jõuab.

Nii ehitatakse seda arhitektuuri, kuidas vabaneda peavalust, kui PM-ist või sidusrühmast tuleb väikseid nõudmiste muudatusi: sellest räägib ka raamat.

Autoritest

Enne kui räägin millestki selle raamatu kohta, tahan natuke endast rääkida.
Praegu olen ma Strong Junior Developer, kes spetsialiseerub teenuste arendamisele ASP .NET CORE abil.

Olen aastast töötanud ühes 'galerii' projektis ja paistab, et järk-järgult saan hakkama.

Olen seda raamatut juba kaks korda lugenud ja soovitan seda kõigile:

• integraaltarkvara arendajatele;
• veebiarendajatele;
• tagaplaanide arendajatele;
• ja isegi dev-ops spetsialistidele.

Lõppude lõpuks, kõigile, kes on seotud tarkvara arendusega, silmas pidades otsest arendust, näiteks erinevaid müügi- ja projektijuhte siia ei kaasata (kuigi oleks kasulik teada, miks arendaja võib ülesande täitmiseks kaks korda rohkem aega kulutada), soovitan seda raamatut lugeda.
Ja nüüd püüan ma põhjendada, miks ma nii arvan.

Veidi autori kohta, sest minu jaoks on autoriteet kirjutaja osas väga oluline. Arvan, et saate minust aru; kuigi see ei ole alati õige, usaldate autoriteetse inimese sõnu rohkem, kui kellelegi, kes on lihtsalt rahvamassist (kes on sümptomeid google'inud).

Robert Martin, tuntud ka kui Uncle Bob (onkli Bob) — töötab programmeerimise valdkonnas, hõlmates erinevaid süsteeme (alates veebi teenustest kuni sisseehitatud süsteemideni) alates 1970. aastast. Ta on tehniline konsultant ja arhitekt, on kirjutanud erinevatesse tehnilistesse ajakirjadesse, olles väga kogenud programmeerija ning inimene, kes mängis üht olulist rolli kõigile tuntud SOLID põhimõtete loomisel (võib öelda, et on nende looja). Samuti tahaksin mainida, et see raamat on mulle soovitanud minu tiimijuht, kes omab rohkem kui 15-aastast töökogemust.

Raamatust

Sõltuvused

Enne raamatu lugemist lugesin ma üsna palju artikleid samal Habr'is, kus kõneldi sellisest sõnast nagu "sõltuvus". Mis see on, kes keda sõltub, mida täpselt tähendab "sõltuda" ja kuidas võib mõni klass sõltuda kelleltki?

Ja raamatu lugemise käigus mõistsin kahte asja:

Sõltuvus on termin, mis tähendab, et mõni klass (komponent, teenus) teab mõnest teisest klassist (komponendist, teenusest) ja see teadmine määratakse kooditasemel (praegu saavad Java, C# ja C keele arendajad mind aru saada) teatud nimede impordiga. Teisisõnu: teil on klass A, mille nimede ruum on Default.Classes, ja klass B, mille nimede ruum on Another.Classes. Kui klassi A allika koodis kasutatakse 'using Another.Classes;', siis see tähendab, et klass A sõltub klassist B.
Skeemi mõistmiseks, kus on sõltuv klass ja kus mitte — vaadake noole suunda: 1) nool osutab klassist A klassi B suunas. See tähendab, et klass B on sõltumatum kui klass A. Ja klassi A muutused ei kahjusta klassi B.

SOLID

Üks peamisi põhjuseid, miks ma selle raamatu lugemist alustasin, oli SOLID printsiipide selgitamine esmaallikast, kuna onu Bob arendas neid printsiipe ja võib öelda, et tänu temale kuuleme seda nime — SOLID.
Neile, kes ei ole kursis — need printsiipe öeldakse ja soovitatakse, et oma rakendusi disainitaks vastavalt viiele reeglile:

S — SRP (Üksiku vastutuse printsiip)
O — OCP (Avatud-suletud printsiip)
L — LSP (Liskovi asenduse printsiip)
I — ISP (Liidese segregatsiooni printsiip)
D — DIP (Sõltuvuse pööramise printsiip)

Kõiki neid printsiibe saab rakendada klasside ja objektide, moodulite ja komponentide ning kihtide (teenuste) tasandil.

Kui arvate, et Üksiku vastutuse printsiip tähendab, et klass või moodul peaks tegema ainult ühte asja — siis peate kindlasti lugema vähemalt peatükki SOLID-i kohta. Sest see eeltoodud määratlus on tagajärg, mitte ei ole printsiibi enda määratlemine.

Sõltuvuse pööramine

Soovin pöörata erilist tähelepanu sõltuvuse inversiooniprinsiibi (D SOLID’ist) selgitusele. Raamatu lugemise käigus mõistsin, et see ei ole lihtsalt põhimõte, vaid ka mehhanism ja tööriist, millega saate muuta oma sõltuvuste suunda ja näiteks teha äriloogika (DOMAIN) sõltumatuks andmejuhtimise kihist (DAL).

Kuigi ise põhimõte SÕLIDis tähendab koos teistega veidi midagi muud kui mehhanism, kasutatakse seda mehhanismi raamatus pidevalt, ning see on üks peamisi meetodeid teie sõltuvuste inversiooniks ja suuna muutmiseks, mida tegelikult kasutatakse DDD-s.

Architektuuriotsuste tegemine

Raamatus mainitakse väga sageli põhimõtet oluliste architektuuriotsuste tegemisest: millist andmebaasi kasutada, millist raamistikku valida, millist teeki siduda, mida kasutada otsingumootorina jne.

Autori arvates peaksite selliseid otsuseid langetama KUI VÕIMALIKULT HARVA. Kuna nõuded võivad muutuda, võivad jõudluse piirangud samuti varieeruda ning käitumuslik komponent kalduvad muutuma. Arendusprotsessi käigus võib üks või teine lahendus osutuda vähem tõhusaks kui teine, vähem mugavaks kui mõni teine. Ja teie arhitektuuri tugevus määrab, kui kiiresti ja valutult suudate ühe tehnoloogia teise vastu vahetada (nagu viitab ka OCP).

Näiteks, ühel hetkel otsustate asendada Postgresql'i MongoDb’ga, või hoopis kasutada faile, või kasutada simuleeritud andmeid, mille operatsioonid toimuvad mälus. Teatud tingimustel võib see sundida ümber kirjutama peaaegu kogu loogika.

Selliste olukordade vältimiseks saame kasutada teatud mehhanisme, mis viivad otsuste langetamise aega maksimaalselt edasi. Üks neist mehhanismidest on abstraktsioon.

Viidatud DDD

DDD — Domain Driven Design — on lähenemine teenuste arendusele, kus on keeruline äriloogika, mis on muutustele kriitiline, ja mis on suunatud projekti juhtivate positsioonide (PM-ide, müügijuhid jne) maksimaalsele mõistmisele, koos rikka arendusega. Eesmärk on, et kõik projekti osalised räägiksid ühte keelt ehk ubiquitous language, mistõttu saaks igaüks teist mõista ning kõik mõtleksid samas domeenis ühiste ärireeglitega.

Kui olete DDD pooldaja, või soovite selleks saada, või kui te ei mõista midagi, aga soovite mõista — siis see raamat on kohustuslik lugemine, eriti raamatu teine osa.

Siin seletab autor, mis on Dependency Rule, ja miks selle järgimine aitab teil luua õige rakenduse arhitektuuri. Miks sõltuvused peavad liikuma suunas, kus on kõrge poliitika komponendid, miks domeeni (kõrge poliitika komponent) peab olema sõltumatu infrastruktuurist ja kuidas see lihtsustab teie juurutamist ja arendust.

Abstraktsioon

Onu Rob räägib ka sellest, kuidas rakenduse üksikasjad võivad kahjustada teie süsteemi ja takistada selle edasist evolutsiooni ilma valudeta.

Pidage meeles!
DB on rakenduse üksikasjalik element.
Kliendid (Web, mobiil jne) — on rakenduse üksikasjad.
Raamistikke on rakenduse teostamise element.

Kõigest sellest tuleb maksimaalselt abstraktselt läheneda ja mitte sõltuda, kasutades ülaltoodud sõltuvuse inversiooni, liideseid ja abstraktsioone, sõltuvuse reeglit ning teisi mehhanisme.

Modulite ülesehitamise meetodid.

See jagu meeldis mulle eriti, kuna olen ASP .NET CORE teenuste arendaja. Siin räägitakse teenuse ühtse arhitektuuri ehitamise metodoloogiatest, kasutades valmis komponente.

Robert kirjeldas 4 võimalikku kihtide lahendamist.

Ta selgitas, miks nii tihti kasutatav kolm kihilist arhitektuuri mehhanism: UI (kontrollerid), teenused (domeen), DAL (andmebaas) on teistega võrreldes piisavalt halb. Olen näinud mitte väga palju projekte, kuid igas, näiteks mikroteenuses, kasutatakse just kolme kihilist arhitektuuri tagaplaanil.

Samuti kasutatakse sageli arhitektuuri, kus üks komponent on üks teenus. Üldiselt on nad mõlemad head, kuid neil on rohkesti miinuseid, võrreldes näiteks DDD kasutamisega, eriti kriitiliselt muudetavates ja keerulistes teenustes.

Kokkuvõttes on see raamatukirjeldus jõudnud lõpule. Mulle meeldis raamat väga, ei kahetse, et seda lugesin. Aitäh autorile. Kallid lugejad, aitäh tähelepanu eest, palun ärge olge liiga ranged – see publikatsioon põhineb raamatu muljetel ja minu isiklikul entusiasmiga.

Allikas: habr.com