Toto bude rozprávanie o dojmoch z knihy, a taktiež budú preskúmané niektoré pojmy a poznatky, ktoré boli vďaka tejto knihe získané.
Architektúra
Môžete, čítajúc túto publikáciu, poskytnúť jasnú odpoveď na otázku, čo je architektúra? Čo znamená architektúra v kontexte programovania a navrhovania? Akú úlohu zohráva? V tomto pojme je dosť nejasností. A zdá sa, že je všetko jasné, ale akosi abstraktné, a bez presnosti. Martin je presvedčený, a ja s ním súhlasím, že aplikácia má dve zložky:
- Správanie (behavior) — funkcie a úlohy, ktoré program (komponent, služba) vykonáva.
- Architektúra — tento pojem sa do veľkej miery týka zmien aplikácie.
Ale aj keď aplikácia veľmi dobre plní úlohu, ktorú má, neznamená to, že má dobrú architektúru. Architektúra nie je o správaní aplikácie. Architektúra je o ľahkosti zmien, architektúra je o ľahkosti nasadenia, architektúra je o nezávislosti vývoja. Architektúra je o rýchlosti, s ktorou nové človek v tíme porozumie.
A takto sa buduje táto architektúra, ako sa zbaviť bolesti hlavy pri malých zmenách požiadaviek od PM-a alebo od akcionára: o tom a povie táto kniha.
O autoroch
Predtým, než poviem niečo o tejto knihe, chcem povedať niečo o sebe.
Momentálne som Strong Junior Developer, špecializujem sa na vývoj služieb prostredníctvom ASP .NET CORE.
Už rok pracujem na jednej „galerke“ a zdá sa, že si s tým postupne porádzam.
Túto knihu som už prečítal 2-krát a odporúčam ju všetkým:
- vývojárom embedded systémov;
- front-end vývojárom;
- back-end vývojárom;
- a dokonca DevOps-om.
V podstate všetkým, ktorí sú aspoň nejako zapojení do vývoja softvéru, hovorím o priamom vývoji, rôzni Sales a PM-ovia sem nie sú zahrnutí (aj keď by bolo užitočné vedieť, prečo Dev trvá dvakrát dlhšie na úlohu), odporúčam prečítať si túto knihu.
A teraz sa pokúsim odôvodniť, prečo to považujem za dôležité.
Trochu o autorovi této knihy (protože pro mě je autorita pisatele velmi důležitá). Myslím, že mě pochopíte, i když to nemusí být vždy správné, ale pokud vám něco říká autoritativní osoba v oboru – projevujete mnohem větší důvěru k jejímu slovu. Například si myslím, že více uvěříte diagnóze, kterou vám stanoví lékař, než někomu z davu (kdo si vygooglil symptomy).
Robert Martin, známý také jako Uncle Bob (strýček Bob), pracuje v oblasti programování, a to různých systémů (od webových služeb po embedded systémy), od roku 1970. Je technickým konzultantem a architektem, psal do různých technických časopisů, je sám o sobě velmi zkušený programátor a osoba, která hrála jednu z klíčových rolí při vytváření známých principů SOLID (dá se říct, že je jejich tvůrcem). Také bych rád dodal, že mi tuto knihu doporučil můj týmový vedoucí s více než 15letou zkušeností.
O knize
Závislosti
Před čtením knihy jsem si přečetl mnoho článků na tomtéž Habr, kde se objevovalo slovo "závislost". Co to vlastně je, kdo na kom závisí, co přesně znamená "záviset" a jak může nějaká třída záviset na někom?
A tak jsem během čtení knihy pochopil dva momenty:
Závislost je termín, který znamená, že nějaká třída (komponenta, služba) zná nějakou jinou třídu (komponentu, službu) a toto vědění na úrovni kódu určují (teď mě dělá česky mluvčí, C# a C programátoři pochopí) určité importy namespace. Jinými slovy: máte třídu A s namespace Default.Classes a třídu B Another.Classes. Pokud tedy ve zdrojovém kódu třídy A figuruje "using Another.Classes;" – znamená to, že třída A závisí na třídě B.
Abyste porozuměli schématu, kde je závislá třída a kde ne – podívejte se na směr šipky: v 1) šipka bude ukazovat od třídy A směrem k třídě B. To znamená, že třída B je nezávislejší než třída A. A změny v třídě A nezpůsobí žádnou "škodu" třídě B.
SOLID
Jedním z hlavních důvodů, proč jsem se rozhodl přečíst tuto knihu – je vysvětlení principů SOLID z primárního zdroje, protože strýček Rob vyvinul tyto principy a dá se říct, díky němu slyšíme toto označení – SOLID.
Pre tých, ktorí nie sú oboznámení — tieto princípy hovoria a odporúčajú navrhovať svoje aplikácie v súlade s piatimi pravidlami:
S — SRP (Princíp jednej zodpovednosti)
O — OCP (Princíp otvorenosti a uzavretosti)
L — LSP (Liskov princíp substitúcie)
I — ISP (Princíp segregácie rozhraní)
D — DIP (Princíp inverzie závislostí)
Všetky tieto princípy môžu byť aplikované na úrovni tried a objektov, na úrovni modulov a komponentov, a na úrovni vrstiev (služieb).
Ak si myslíte, že Princíp jednej zodpovednosti znamená, že trieda alebo modul by mal robiť len jednu vec — určite by ste si mali prečítať aspoň kapitolu o SOLID. Pretože to definovanie vyššie je následok, ale nie definícia samotného princípu.
O Inverzii Závislostí
Chcem zvlášť upozorniť na vysvetlenie Princípu inverzie závislostí (to, čo je D zo SOLID). Počas čítania knihy som si uvedomil, že to nie je len princíp, je to aj mechanizmus a nástroj, pomocou ktorého môžete meniť smer vašich závislostí, a robí napríklad biznis logiku (DOMAIN) nezávislou od detailov implementácie vrstvy prístupu k dátam (DAL).
Hoci samotný princíp, podobne ako ostatné v SOLID, znamená niečo trochu iné ako mechanizmus, samotný mechanizmus sa používa počas celej knihy, a to je jeden z hlavných spôsobov, ako invertovať a meniť smer vašich závislostí, ktorý sa, mimochodom, používa pri DDD.
O prijímaní architektonických rozhodnutí
Veľmi často sa v knihe spomína princíp prijímania dôležitých architektonických rozhodnutí: o tom, akú databázu použiť, aký framework použiť, akú knižnicu pripojiť, čo použiť ako vyhľadávací engine atď.
Takže autor tvrdí: mali by ste prijímať takého rozhodnutia KĽÚČOVO MENEJ. Pretože požiadavky sa môžu meniť, obmedzenia týkajúce sa výkonu tiež, sama behaviorálna zložka má tendenciu sa meniť. Počas vývoja sa nejaké rozhodnutie môže zdať menej efektívne ako iné, menej pohodlné ako iné. A sila vašej architektúry určí, ako rýchlo a bezbolestne budete môcť nahradiť jednu technológiu druhou (o čom mimochodom hovorí OCP).
Napríklad, náhle sa rozhodnete použiť namiesto Postgresql MongoDb, alebo dokonca súbory, alebo používať mockované dáta, s ktorými sa bude pracovať v pamäti. A za určitých podmienok — to môže vyžadovať prepis takmer celej logiky.
Aby sa takéto situácie nevyskytovali, môžeme použiť niektoré mechanizmy, ktoré posunú čas rozhodovania čo najďalej. Jeden z týchto mechanizmov je abstrakcia.
Odkazy na DDD
DDD – Design riadený doménou – je prístup k návrhu služieb so zložitou obchodnou logikou, kritickou na zmeny, ktorý je zameraný na maximálne pochopenie projektovými manažérmi (PMs, predajnými manažérmi atď.) a bežnými pracovníkmi. Tým pádom je potrebné, aby všetci členovia projektu mali ubiquituálny jazyk, každý mohol pochopiť druhého a všetci mysleli na jednodomninou s rovnakými obchodnými pravidlami.
Ak ste prívržencom DDD, alebo sa ním chcete stať, alebo ak v tom vôbec nerozumiete, ale chcete rozumieť – táto kniha je povinná na prečítanie, najmä druhá časť knihy.
Tu autor vysvetľuje existenciu pravidla závislosti a prečo, ak mu budete dodržiavať, budete budovať správnu architektúru aplikácie. Prečo by závislosti mali smerovať k komponentom s vysokou politikou, prečo domény (komponent s vysokou politikou) by mal byť nezávislý od infraštruktúry a ako to uľahčí nasadzovanie a vývoj.
Abstrahovanie
Strýko Rob tiež rozpráva o tom, ako realizácie môžu uškodiť vašej sústave a nedovoliť jej evolvovať bez bolesti v budúcnosti.
Pamätajte!
DB je detail realizácie.
Klienti (Web, Mobilné atď.) sú detaily realizácie.
Frameworky sú detaily realizácie.
Od tohto všetkého je potrebné sa maximálne abstrahovať a nezávisieť na ňom, pričom sa využíva vyššie opísaný inverzný mechanizmus závislosti s rozhraniami a abstrakciami, pravidlo závislosti a iné mechanizmy.
Metódy budovania modulov
Táto časť sa mi obzvlášť páčila, ako vývojárovi služieb na ASP .NET CORE, pretože sa tu rozpráva o metodológiách budovania jednotnej architektúry služby z hotových komponentov.
Robert opísal 4 možné schémy rozdelenia vrstiev.
Dá sa to pochopiť, prečo je tak často používaný mechanizmus trojvrstvovej architektúry: UI (ovládače), Služby (doména), DAL (databáza) – dosť zlý v porovnaní s inými. Viděl som nie príliš veľa projektov, ale v každom, napríklad mikroservise, sa na backendu používa práve trojvrstvá architektúra.
Takisto sa často používa architektúra jeden-komponent-jeden-servis. Všeobecne sú obidve celkom dobré, no táto má pomerne veľa nevýhod v porovnaní s architektúrou založenou na DDD, najmä pri kritických zmenách a zložitých službách.
A tak sa skončila táto recenzia na knihu. Kniha sa mi veľmi páčila, neľutujem prečítané, ďakujem autorovi. Vám, vážení čitatelia, ďakujem za pozornosť, nesúďte príliš strikne — tento príspevok je založený na dojmoch z knihy a mojom osobnom nadšení.
Zdroj: habr.com
