Toto bude příběh o dojmech z knihy a také se zde projednají některé pojmy a znalosti, které díky této knize byly získány.
Architektura
Můžete při čtení této publikace dát jasnou odpověď na otázku, co je architektura? Co znamená architektura v kontextu programování a designu? Jakou roli hraje? Existuje spousta nejasností kolem tohoto termínu. Ačkoliv to vypadá jasně, je to poněkud abstraktní a bez přesnosti. Martin se domnívá, a já s ním souhlasím, že aplikace má dvě složky:
- Chování (behavior) — funkce a úkoly, které program (komponenta, služba) vykonává.
- Architektura — tento termín se více týká změny aplikace.
Avšak i když aplikace velmi dobře plní úkol, který má vykonávat, neznamená to, že má dobrou architekturu. Architektura není o chování aplikace. Architektura je o snadnosti změn, architektura je o snadnosti nasazení, architektura je o nezávislosti vývoje. Architektura je o rychlosti, s jakou nový člen týmu porozumí aplikaci.
A jak tuto architekturu budovat, jak se zbavit bolesti hlavy při drobných změnách požadavků od PM nebo stakeholdera: o tom a bude tato kniha hovořit.
O autorech
Předtím, než něco řeknu o této knize, chci říct něco málo o sobě.
V současné době jsem Strong Junior Developer, specializuji se na vývoj služeb pomocí ASP .NET CORE.
Už rok pracuji na jednom "galerií" a zdá se, že si s tím tak nějak poradím.
Tuto knihu jsem přečetl už dvakrát a doporučuji ji všem:
- vývojářům embedded systémů;
- frontendovým vývojářům;
- backendovým vývojářům;
- a dokonce i devopsákům.
Obecně všem, kdo se nějakým způsobem podílejí na vývoji software, tj. přímé vývoji různých Sales a PM sem nezapočítáváme (ačkoli by také bylo užitečné vědět, proč dev stráví dvakrát více času na úkolu), doporučuji přečíst tuto knihu.
A nyní se pokusím argumentovat, proč to myslím vážně.
Trochu o autorovi této knihy (protože pro mě má autorita autora velký význam). Myslím, že mě pochopíte, i když to není vždy správné, ale pokud vám něco říká autoritativní osoba v oboru — projevujete mnohem větší důvěru k tomu, co říká. Například věřím, že více uvěříte diagnóze, kterou vám stanoví lékař, než od nějakého člověka z davu (kdo si vygooglil příznaky).
Robert Martin — známý také jako Uncle Bob — pracuje v oblasti programování, různých systémů (od webových služeb po embed systémy) od roku 1970. Je technickým konzultantem a architektem, psal do různých technických časopisů, sám je velmi zkušený programátor a člověk, který hrál jednu z klíčových rolí při vytváření známých principů SOLID (lze říci, že je tvůrcem). Také bych chtěl dodat, že mi tuto knihu doporučil můj týmový vedoucí s více než 15 lety zkušeností.
O knize
Závislosti
Před přečtením knihy jsem četl spoustu článků na stejném Habré, kde se objevovalo slovo „závislost“. Co to je, kdo na kom závisí, co konkrétně znamená „záviset“, a jak může nějaká třída záviset na někom?
A tak při čtení knihy jsem si osvojil dvě věci:
Závislost — to je termín, který znamená, že nějaká třída (komponent, služba) ví o nějaké jiné třídě (komponentě, službě), a toto vědění na úrovni kódu je určeno (teď mě chápou jazykáři jako Java, C# nebo C) určitým importem namespace. Jinými slovy: máte třídu A s namespace Default.Classes a třídu B Another.Classes. Takže pokud v kódu třídy A bude použití using Another.Classes; — znamená to, že třída A závisí na třídě B.
Abychom pochopili na schématu, kde je závislá třída a kde není — 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 si tuto knihu přečetl — je to vysvětlení principů SOLID z primárního zdroje, protože strýc Bob tyto principy vyvíjel a lze říci, že díky němu slyšíme toto označení — SOLID.
Pro ty, kteří nejsou obeznámeni — tato pravidla doporučují navrhovat aplikace podle 5 principů:
S — SRP (Princip jediné odpovědnosti)
O — OCP (Princip otevřenosti a uzavřenosti)
L — LSP (Liskovův substituční princip)
I — ISP (Princip segregace rozhraní)
D — DIP (Princip inverze závislostí)
Všechny tyto principy lze aplikovat na úrovni tříd a objektů, na úrovni modulů a komponent a na úrovni vrstev (služeb).
Pokud se domníváte, že Princip jediné odpovědnosti říká, že třída nebo modul by měly dělat pouze jednu věc — měli byste si přečíst alespoň kapitolu o SOLID. Neboť ta definice, kterou jsme uvedli výše — je důsledkem, ale nikoli definicí samotného principu.
O Inverzi závislostí
Zvláštní pozornost bych rád věnoval vysvětlení Principu inverze závislostí (ten, co je D z SOLID). Během čtení knihy jsem si uvědomoval, že to není jen princip, ale také mechanismus a nástroj, s jehož pomocí můžete měnit směry svých závislostí a udělat například obchodní logiku (DOMAIN) nezávislou na podrobnostech implementace vrstvy přístupu k datům (DAL).
Ačkoliv samotný princip v SOLID znamená něco trochu jiného než mechanismus, tento mechanismus se používá v celé knize a je to jeden z hlavních metod, jak inverzovat a měnit směry vašich závislostí, který se mimochodem používá v DDD.
O přijetí architektonických rozhodnutí
Velmi často se v knize zmiňuje princip přijetí důležitých architektonických rozhodnutí: jakou databázi použít, jaký rámec použít, kterou knihovnu připojit, co použít jako vyhledávač atd.
Autor se domnívá, že byste měli CO NEJMÉNĚ přijímat tohoto druhu rozhodnutí. Neboť požadavky se mohou měnit, omezení výkonu také, a samotná behaviorální složka má tendenci se měnit. Během vývoje se může nějaké rozhodnutí zdát méně efektivní než jiné, méně pohodlné než jiné. A síla vaší architektury určí, jak rychle a bezbolestně budete schopni nahradit jednu technologii jinou (o tom mimochodem tvrdí OCP).
Například, náhle se rozhodnete použít místo Postgresql MongoDB, nebo dokonce soubory, nebo použít mockovaná data, s nimiž budou operace prováděny v paměti. A za určitých podmínek — to může vyžadovat přepsání téměř celé logiky.
Aby se takové situace nevyskytovaly, můžeme využít určité mechanismy, které co nejvíce oddálí čas rozhodování. Jedním z těchto mechanismů je abstrakce.
Odkazy na DDD
DDD – Domain Driven Design – je přístup k vývoji služeb s komplexní obchodní logikou, kritickou vůči změnám, zaměřený na maximální pochopení vedoucími pracovníky projektu (PM, prodejní manažeři atd.) a běžnými pracovníky. To znamená, že mezi všemi členy projektu existuje ubiquitous language, a každý rozumí ostatním, a aby všichni přemýšleli v jednom doméně se stejnými obchodními pravidly.
Pokud jste zastáncem DDD, nebo chcete být takovým, nebo něčemu v tom nerozumíte, ale chcete porozumět – kniha je povinná četba, zejména druhá část knihy.
Zde autor vysvětluje existenci Dependency Rule a proč, pokud se jí budete řídit – budete stavět správnou architekturu aplikace. Proč by závislosti měly směřovat k High Policy komponentům, proč. doména (High Policy komponent) by měl být nezávislý na infrastruktuře a jak to usnadní nasazení a vývoj.
Abstrakce
Pan Rob také hovoří o tom, jak detaily implementace mohou poškodit váš systém a neumožnit mu evolvovat bez bolesti v budoucnu.
Pamatujte!
DB je detail implementace.
Klienti (Web, Mobilní atd.) jsou detaily implementace.
Frameworky jsou detaily implementace.
Je třeba se od toho všeho co nejvíce abstrahovat a nezáviset na tom, využívající výše popsanou Dependency Inversion s rozhraními a abstrakcemi, Dependency Rule a další mechanismy.
Metody budování modulů
Tato část se mi obzvlášť líbila jako vývojáři služeb na ASP.NET CORE. Neboť zde se hovoří o metodologiích budování jednotné architektury služby z hotových komponentů.
Robert popsal čtyři možné schémata rozdělení vrstev.
Dával najevo, proč je tak často používaný mechanismus třívrstvé architektury: UI (kontrolery), Služby (Doména), DAL (Databáze) – poměrně slabý v porovnání s ostatními. Neviděl jsem moc projektů, ale v každém, například mikroservisu, se na backendu používá právě třívrstvá architektura.
Také se často používá architektura jeden komponent - jeden servis. Celkově jsou obě možnosti dobré, ale mají spoustu nevýhod ve srovnání s tím, jak je postavena architektura při použití DDD, zejména u systémů, které jsou citlivé na změny a složitých služeb.
Celkově skončil tento přehled knihy. Kniha se mi opravdu líbila, nelituji času stráveného čtením, děkuji autorovi. Vám, milí čtenáři, děkuji za pozornost, nehodnoťte mě příliš přísně — tento příspěvek je založen na mých dojmech z knihy a osobním nadšení.
Zdroj: habr.com
