Dit zal een verhaal zijn over de indruk van een boek, en er zullen ook enkele concepten en kennis worden behandeld die door dit boek zijn bestudeerd.
Architectuur
Kun je, terwijl je deze publicatie leest, een duidelijk antwoord geven op de vraag: wat is architectuur? Wat is architectuur in de context van programmeren en ontwerpen? Welke rol speelt het? Er is best veel onduidelijkheid over deze term. Het lijkt allemaal wel duidelijk, maar het is op de een of andere manier abstract en zonder precisie. Martin denkt, en ik ben het met hem eens, dat een applicatie twee componenten heeft:
- Gedrag (behavior) — de functies en taken die het programma (component, service) uitvoert.
- Architectuur — deze term gaat in grotere mate over de verandering van een applicatie.
Maar zelfs als de applicatie de taak die het moet uitvoeren heel goed vervult, betekent dat nog niet dat het een goede architectuur heeft. Architectuur gaat niet om het gedrag van de applicatie. Architectuur gaat om de eenvoud van wijzigbaarheid, architectuur gaat om de eenvoud van implementatie, architectuur gaat om de onafhankelijkheid van ontwikkeling. Architectuur gaat om de snelheid waarmee een nieuw lid van het team het begrijpt.
En zo bouw je deze architectuur, hoe je de hoofdpijn kunt vermijden bij kleine wijzigingen in de eisen van de PM of van de stakeholder: daarover zal het boek vertellen.
Over de auteurs
Voordat ik iets over dit boek zeg, wil ik iets over mezelf vertellen.
Op dit moment ben ik een Strong Junior Developer, gespecialiseerd in het ontwikkelen van services met ASP .NET CORE.
Ik werk al een jaar bij een 'gallery', en ik lijkt het een beetje onder de knie te krijgen.
Ik heb dit boek al twee keer gelezen, en ik raad het aan iedereen aan:
- ontwikkelaars van embedded systemen;
- frontend-ontwikkelaars;
- backend-ontwikkelaars;
- en zelfs DevOps.
Kortom, iedereen die op enige manier betrokken is bij softwareontwikkeling, met name directe ontwikkeling van verschillende Sales; PM's tel ik hier niet bij, hoewel het ook nuttig zou zijn om te weten waarom een dev soms twee keer zoveel tijd aan een taak besteedt, raad ik aan dit boek te lezen.
En nu zal ik proberen te argumenteren waarom ik dat vind.
Een beetje over de auteur van dit boek (want voor mij speelt de autoriteit van de schrijver een grote rol). Ik denk dat je me zal begrijpen, hoewel dit niet altijd juist is, maar als iemand met autoriteit in het vakgebied iets zegt - heb je veel meer vertrouwen in wat hij zegt. Bijvoorbeeld, ik denk dat je meer geloof zult hechten aan de diagnose die een arts stelt, dan aan die van een random persoon uit de menigte (die de symptomen heeft gegoogeld).
Robert Martin - ook wel Uncle Bob genoemd - werkt sinds 1970 in de programmeerwereld, in verschillende systemen (van webservices tot embedded systemen). Hij is technisch adviseur en architect, heeft geschreven voor verschillende technische tijdschriften, is zelf een zeer ervaren programmeur, en een persoon die een van de sleutelrollen speelde bij het creëren van de algemeen bekende SOLID-principes (je zou kunnen zeggen dat hij de oprichter is). Ook wil ik toevoegen dat mijn teamleider met meer dan 15 jaar ervaring me dit boek heeft aangeraden.
Over het boek
Afhankelijkheden
Voor het lezen van het boek heb ik veel artikelen op dezelfde site gelezen, waarin het woord ‘afhankelijkheid’ werd genoemd. Wat is dat precies, wie is van wie afhankelijk, wat betekent het concreet om ‘afhankelijk’ te zijn, en hoe kan een bepaalde klasse afhankelijk zijn van een andere?
En terwijl ik het boek las, heb ik twee momenten begrepen:
Afhankelijkheid is een term die betekent dat een bepaalde klasse (component, service) op de hoogte is van een andere klasse (component, service), en deze kennis wordt op code-niveau gedefinieerd (nu zullen Java-ontwikkelaars, C#-ontwikkelaars en C-ontwikkelaars begrijpen) door een bepaalde import van een namespace. Met andere woorden: als je klasse A hebt met de namespace Default.Classes en klasse B Another.Classes. Dan betekent het dat als in de broncode van klasse A using Another.Classes; voorkomt - dat klasse A afhankelijk is van klasse B.
Om op de diagram te zien waar de afhankelijke klasse is en waar niet - kijk naar de richting van de pijl: in 1) de pijl wijst van klasse A naar klasse B. Dit betekent dat klasse B onafhankelijker is dan klasse A. En veranderingen in klasse A zullen geen ‘schade’ toebrengen aan klasse B.
SOLID
Een van de belangrijkste redenen die mij aanspoorde om dit boek te lezen was de uitleg van de SOLID-principes vanuit de eerste bron, omdat Uncle Bob deze principes heeft ontwikkeld en je zou kunnen zeggen dat we dankzij hem deze naam - SOLID - kennen.
Voor diegenen die het niet weten: deze principes raden aan om je applicaties te ontwerpen volgens 5 regels:
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)
Al deze principes kunnen worden toegepast op het niveau van klassen en objecten, op het niveau van modules en componenten, en op het niveau van lagen (diensten).
Als je denkt dat het Single Responsibility Principle betekent dat een klasse of module maar één ding moet doen, dan moet je absoluut het hoofdstuk over SOLID lezen. Want de definitie die hierboven is gegeven, is een gevolg, maar absoluut niet de definitie van principe zelf.
Over Dependency Inversion
Ik wil speciale aandacht besteden aan de uitleg van het Dependency Inversion Principle (de D van SOLID). Terwijl ik het boek las, begreep ik dat dit niet slechts een principe is; het is ook een mechanisme en instrument waarmee je de richting van je afhankelijkheden kunt veranderen, waardoor je bijvoorbeeld de bedrijfslogica (DOMAIN) onafhankelijk maakt van de implementatiedetails van de Data Access Layer (DAL).
Hoewel het principe zelf, net als de andere in SOLID, iets anders betekent dan het mechanisme, wordt het mechanisme door het hele boek heen gebruikt. Dit is een van de belangrijkste methodes om de richting van je afhankelijkheden te inverseren en te veranderen, en wordt bovendien gebruikt bij DDD.
Over het nemen van architecturale beslissingen
In het boek zal vaak het principe worden genoemd van het nemen van belangrijke architecturale beslissingen: welke database te gebruiken, welk framework te kiezen, welke bibliotheek te integreren, welke zoekmachine te gebruiken, enzovoort.
De auteur is van mening dat je ZOVEEL MOGELIJK minder van dit soort beslissingen moet nemen. Want de requirements kunnen veranderen, de beperkingen qua performance ook, en zelf de gedragscomponent heeft de neiging te veranderen. Gedurende het ontwikkelingsproces kan een bepaalde beslissing minder effectief blijken dan een andere, minder handig dan een andere. De kracht van je architectuur zal bepalen hoe snel en soepel je één technologie kunt vervangen door een andere (daarover spreekt OCP trouwens ook).
Bijvoorbeeld, plotseling besluit je om in plaats van PostgreSQL MongoDB of zelfs bestanden te gebruiken, of om gemockte gegevens te gebruiken, waarmee in het geheugen operaties worden uitgevoerd. En onder bepaalde omstandigheden kan dit je dwingen om bijna de hele logica opnieuw te schrijven.
Om dergelijke situaties te voorkomen, kunnen we verschillende mechanismen gebruiken die de besluitvorming zo ver mogelijk uitstellen. Een van deze mechanismen is abstractie.
Verwijzingen naar DDD
DDD — Domain Driven Design — is een benadering voor de ontwikkeling van services met complexe bedrijfslogica die kritisch is voor veranderingen, gericht op een maximaal begrip van de leidinggevende posities in het project (PM's, verkoopmanagers, enz.), met de gewone teamleden. Dit betekent dat er tussen alle leden van het project een ubiquitous language moet zijn, zodat iedereen elkaar kan begrijpen en ze allemaal in hetzelfde domein denken met dezelfde zakelijke regels.
Als je een voorstander bent van DDD, of wilt zijn, of als je iets hiervan niet begrijpt maar het wel wilt begrijpen — dit boek is een must-read, vooral het tweede deel van het boek.
Hier legt de auteur uit over het bestaan van de Dependency Rule, en waarom als je deze volgt — je de juiste architectuur van de applicatie zult bouwen. Waarom afhankelijkheden in de richting van High Policy componenten moeten gaan, waarom domein (High Policy component) onafhankelijk moet zijn van infrastructuur en hoe dat je implementatie en ontwikkeling zal vereenvoudigen
Abstractie
Oom Rob legt ook uit hoe implementatiedetails je systeem kunnen schaden en het moeilijk kunnen maken om in de toekomst zonder pijn te evolueren.
Vergeet niet!
DB is een implementatiedetail
Klanten (Web, Mobiel, enz.) zijn implementatiedetails
Frameworks zijn implementatiedetails
Je moet je zo veel mogelijk van dit alles abstraheren en er niet van afhankelijk zijn, door gebruik te maken van de hierboven beschreven Dependency Inversion met interfaces en abstracties, Dependency Rule en andere mechanismen
Methoden voor het bouwen van modules
Deze sectie sprak me bijzonder aan als ontwikkelaar van services op ASP .NET CORE. Hier worden de methodologieën voor het opbouwen van een uniforme service-architectuur uit kant-en-klare componenten besproken.
Robert beschreef 4 mogelijke schema's voor het scheiden van lagen.
Hij maakte duidelijk waarom het vaak gebruikte mechanisme van de drie-laagse architectuur: UI (controllers), Services (Domain), DAL (Database) — behoorlijk slecht is in vergelijking met andere. Ik heb niet zoveel projecten gezien, maar in elk, bijvoorbeeld microservice, wordt precies de drie-laagse architectuur op de backend gebruikt.
Even vaak wordt de één-component-één-dienst architectuur gebruikt. Over het algemeen zijn ze beide redelijk, maar deze heeft behoorlijk wat nadelen in vergelijking met de architectuur die bijvoorbeeld bij DDD wordt toegepast, vooral bij wijzigingen en ingewikkelde diensten.
In het algemeen is deze recensie van het boek ten einde gekomen. Ik vond het boek zelf heel leuk, ik heb er geen spijt van dat ik het heb gelezen, bedankt aan de auteur. Jullie, beste lezers, bedankt voor jullie aandacht, oordeel niet te hard — deze publicatie is gebaseerd op mijn indruk van het boek en mijn persoonlijke enthousiasme.
Bron: habr.com
