Lühidalt kõige olulisest: Clean Architecture, Robert C. Martin

See on räägib raamatu muljetest, samuti käsitletakse mõningaid mõisteid ja teadmisi, mis tänu sellele raamatule on omandatud.

Arhitektuur

Kas sa, lugedes seda publikatsiooni, saad anda selge vastuse küsimusele, mis on arhitektuur? Mis on arhitektuur programmeerimise ja projekteerimise kontekstis? Milline roll tal on? Selle termini osas on siiski palju ebaselgust. Tundub, et kõik on selge, kuid kuidagi abstraktne ja ilma täpsuseta. Martin peab, ja mina nõustun temaga, et rakendusel on kaks komponenti:

1. Käitumine (behavior) — funktsioonid ja ülesanded, mida programm (komponent, teenus) täidab.
2. Arhitektuur — see termin räägib eelkõige rakenduse muutmisest.

Kuid isegi kui rakendus täidab väga hästi ülesannet, mida ta peab täitma, ei tähenda see, et tal on hea arhitektuur. Arhitektuur ei ole rakenduse käitumise kohta. Arhitektuur on kergesti muudetavuse, arhitektuur on kergesti juurutamise, arhitektuur on arendamise sõltumatuse kohta. Arhitektuur on kiirus, millega uuele tiimiliikmele arusaamine tuleb.

Ja kuidas seda arhitektuuri ehitada, kuidas vabaneda peavalust väikeste nõudmiste muutuste tõttu PM-ilt või sidusrühmalt: sellest räägibki raamat.

Autoritest

Enne kui ma midagi räägin selle raamatuga seoses, tahan öelda natuke enda kohta.
Praegu olen ma Strong Junior Developer, spetsialiseerudes teenuste arendamisele ASP .NET CORE abil.

Olen juba aasta töötanud ühes 'galeris', ja tundub, et hakkama saan.

Seda raamatut olen juba kaks korda lugenud, ja soovitan lugemist kõigile:

• süsteemide arendajatele;
• front-end arendajatele;
• back-end arendajatele;
• ja isegi devopsidele.

Kokkuvõttes soovitan lugeda kõigile, kes on kuidagi seotud tarkvara arendamisega, mõtlen just otsese arendusega erinevate Sealide ja PM-ide kohta siin ei arvestata (kuigi oleks ka kasulik teada, miks arendaja kulutab ülesandele kaks korda rohkem aega), soovitan seda raamatut lugeda.
Ja nüüd püüan argumenteerida, miks ma nii arvan.

Veidi autori kohta sellest raamatust (kuna minu jaoks mängib autori autoriteet suurt rolli). Ma arvan, et te hakkate mind mõistma, kuigi see ei ole alati õige, kuid kui autoriteetne inimene valdkonnas ütleb midagi, tunnete te sellele palju rohkem usaldust. Näiteks usun, et usalte rohkem arsti poolt määratud diagnoosi kui mõne suvalise inimesel rahvas, kes on lihtsalt sümptomeid internetist otsinud.

Robert Martin, tuntud ka kui Unkle Bob (onu Bob) — on töötanud programeerimise valdkonnas, hõlmates erinevaid süsteeme (veebiteenustest kuni integreeritud süsteemideni) alates 1970. aastast. Ta on tehniline konsultant ja arhitekt, on kirjutanud erinevatesse tehnilistesse ajakirjadesse, on iseenesest väga kogenud programmeerija ja inimene, kes mängis üht võtmerolli maailmakuulsate SOLID printsiipide loomisel (võib öelda, et nende looja). Samuti tahaksin lisada, et see raamat soovitas mulle minu tiimijuht, kellel on üle 15-aastane töökogemus.

Raamatust

Sõltuvused

Enne raamatu lugemist lugesin ma üsna palju artikleid samal Habr'i lehel, kus figureeris sõna „sõltuvus“. Mis see on, kes kellelt sõltub, mida täpselt tähendab „sõltuda“ ja kuidas mõni klass võib kellestki sõltuda?

Ja raamatu lugemise käigus mõistsin kaks asjaolu:

Sõltuvus on termin, mis tähendab, et mingi klass (komponent, teenus) teab mingist teisest klassist (komponendist, teenusest), ja see teadmine määratakse koodi tasandil (nüüd saavad Java, C# ja C-i programmeerijad mind mõista) kindla nimetu ruumi importimise kaudu. Teisisõnu: teil on klass A nimetu ruumiga Default.Classes ja klass B Another.Classes. Nii et kui klass A allika koodis kasutab using Another.Classes; — tähendab see, et klass A sõltub klassist B.
Selleks, et mõista skeemil, 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 vähem sõltuv kui klass A. Ja muudatused klassis A ei kahjusta klassi B.

SOLID

Üks peamine põhjus, miks ma seda raamatut lugesin, oli SОLID printsiipide selgitamine esmaste allikate kaudu, kuna onu Rob töötas nende printsiipide välja ja võib öelda, et just tema tõttu kuuleme selle nime — SOLID.
Needless to say, these principles suggest and recommend designing your applications according to 5 rules:

S — SRP (Single Responsibility Principle)
O — OCP (Open-Closed Principle)
L — LSP (Liskov Substitution Principle)
I — ISP (Interface Segregation Principle)
D — DIP (Dependency Inversion Principle)

All these principles can be applied at the levels of classes and objects, modules and components, and layers (services).

If you think that the Single Responsibility Principle means that a class or module should only do one thing, then you definitely need to read at least the chapter about SOLID. Because that definition given above is a consequence, but not the definition of the principle itself.

About Dependency Inversion

I would like to pay special attention to the explanation of the Dependency Inversion Principle (the D from SOLID). While reading the book, I realized that it's not just a principle; it’s also a mechanism and tool that allows you to change the direction of your dependencies and make, for example, your business logic (DOMAIN) independent from the implementation details of the Data Access Layer (DAL).

Although the principle itself, along with the others in SOLID, means something slightly different from the mechanism, this mechanism is used throughout the book, and it is one of the main methods for inverting and changing the direction of your dependencies, which is also used in DDD.

On Making Architectural Decisions

The book will often mention the principle of making important architectural decisions: regarding which database to use, which framework to use, which library to include, what to use as a search engine, etc.

The author believes that you should make SUCH decisions AS LITTLE AS POSSIBLE. Because requirements can change, performance constraints can also change, and the behavioral aspect has a tendency to change. During development, some solution may seem less effective than another, less convenient than another. The strength of your architecture will determine how quickly and painlessly you can replace one technology with another (by the way, OCP emphasizes this).

For example, suddenly, you may decide to use MongoDB instead of PostgreSQL, or even files, or use mocked data with which operations will be performed in memory. And under certain conditions, this may require rewriting almost all logic.

Selle vältimiseks saame kasutada mõningaid mehhanisme, mis viivad otsuse tegemise aega maksimaalselt kaugele. Üks neist mehhanismidest on abstraktsioon.

Viidatud DDD-le

DDD — Domeenipõhine disain — lähenemine teenuste arendamisele keerulise äri loogikaga, mis on muutuste suhtes kriitiline ja mis on suunatud projekti juhtide (PM-id, müügijuhid jne) maksimaalsele arusaamisele, et rikkaid andmeid saaksid mõista projektiga seotud inimesed. See tähendab, et kõik projekti liikmed kasutavad ühte ja sama keelt ja saavad üksteisest aru, et kõik mõtleksid ühiselt ühes domeenis lähtudes ühtsetest äri reeglitest.

Kui olete DDD pooldaja, soovite seda olla või te ei saa sellest aru, aga soovite aru saada — raamat on kohustuslik lugeda, eriti raamatu teine osa.

Siin selgitab autor Sõltuvuse reegli olemasolu, ja miks, järgides seda — ehitate te rakenduse õiget arhitektuuri. Miks sõltuvused peaksid liikuma kõrge poliitika komponente; miks domeen (Kõrge poliitika komponent) peab olema sõltumatu infrastruktuurist ja kuidas see lihtsustab teie juurutamist ja arendamist

Abstraktsioon

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

Pidage meeles!
Andmebaas on rakenduse detail
Kliendid (Web, Mobile jne) — rakenduse detailid
Raamistikud on rakenduse detailid

Kõikidest nendest tuleb maksimaalselt abstraktselt eralduda ja mitte sõltuda, kasutades ülaltoodud sõltuvuse pööramise põhimõtet liideste ja abstraktsioonide ning Sõltuvuse reegli ja muude mehhanismide abil

Moodulite loomise meetodid

See jaotis meeldis mulle eriti, kuna olen teenuste arendaja ASP .NET CORE-is. Siin räägitakse meetoditest, kuidas luua ühtne teenuse arhitektuur valmis komponentidest.

Robert kirjeldas 4 võimaliku kihistiku jagamise skeemi.

Ta andis mõista, miks nii sageli kasutatav kolme kihiga arhitektuuri mehanism: UI (kontrollerid), Teenused (Domeen), DAL (Andmebaas) — on võrreldes teistega üsna halb. Olen näinud mitte palju projekte, kuid igas, näiteks mikroteenuses, kasutatakse just kolme kihiga arhitektuuri.

Samuti kasutatakse sageli arhitektuuri üks-komponent-üks-teenus. Üldiselt on mõlemad head, kuid sellel on piisavalt palju puudusi, võrreldes näiteks DDD kasutamise arhitektuuriga, eriti kriitiliste muudatuste ja keeruliste teenuste puhul.

Kokkuvõttes jõudsin selle raamatu ülevaate lõpuni. Raamat ise mulle väga meeldis, ei kahetse loetut, tänan autorit. Teile, kallid lugejad, aitäh tähelepanu eest, ärge olge liiga karmid — see publikatsioon põhineb muljetest raamatust ja minu isiklikust entusiasmist.

Allikas: habr.com