Dette vil være en fortælling om indtrykket af en bog, og der vil også blive behandlet nogle begreber og viden, som takket være denne bog er blevet udvidet.
Arkitektur
Kan du, mens du læser dette indlæg, give et klart svar på spørgsmålet: hvad er arkitektur? Hvad er arkitektur i konteksten af programmering og design? Hvilken rolle spiller den? Der er en del uklarheder i dette begreb. Det virker som om, alt er klart, men alligevel abstrakt og uden præcision. Martin mener, og jeg er enig med ham, at en applikation har to komponenter:
- Adfærd (behavior) — de funktioner og opgaver, som programmet (komponenten, servicen) udfører.
- Arkitektur — dette begreb handler i højere grad om ændring af applikationen.
Men selv hvis applikationen fungerer meget godt til det, den skal, betyder det ikke, at den har en god arkitektur. Arkitektur handler ikke om applikationens adfærd. Arkitektur handler om letheden ved ændringer, arkitektur handler om letheden ved implementering, arkitektur handler om uafhængighed i udviklingen. Arkitektur handler om den hastighed, hvormed forståelse kommer til et nyt medlem af teamet.
Og sådan bygger man denne arkitektur, hvordan man slipper for hovedpinen ved små ændringer af kravene fra PM'en eller interessenterne: det vil bogen fortælle om.
Om forfatterne
Før jeg siger noget om denne bog, vil jeg gerne fortælle lidt om mig selv.
I øjeblikket er jeg Strong Junior Developer, der specialiserer sig i udvikling af tjenester ved hjælp af ASP .NET CORE.
Jeg har arbejdet et år i en 'galleri', og det ser ud til, at jeg klarer mig okay.
Jeg har allerede læst denne bog to gange, og jeg anbefaler den til alle:
- udviklere af embedded-systemer;
- frontend-udviklere;
- backend-udviklere;
- og endda devops.
Generelt til alle, der på en eller anden måde er involveret i softwareudvikling, om det gælder direkte udvikling af forskellige ting, sælgere og PM'er tæller ikke med (selvom det også ville være nyttigt at vide, hvorfor udviklere ofte bruger to gange så lang tid på en opgave), anbefaler jeg at læse denne bog.
Og nu vil jeg forsøge at argumentere for, hvorfor jeg mener det.
Lidt om forfatteren af denne bog (fordi for mig spiller forfatterens autoritet en stor rolle). Jeg tror, du forstår mig, selvom det ikke altid er korrekt, men hvis en autoritativ person inden for området siger noget, viser du langt mere tillid til det, de siger. For eksempel tror jeg, du vil have mere tillid til den diagnose, som en læge sætter på dig, end til hvad som helst en person fra mængden (der har googlet symptomer) siger.
Robert Martin — også kendt som Uncle Bob — har arbejdet inden for programmering siden 1970, og han har erfaring med forskellige systemer (fra webtjenester til indlejrede systemer). Han er teknisk rådgiver og arkitekt, har skrevet til forskellige tekniske tidsskrifter, er en meget erfaren programmør og har spillet en af de nøglemæssige roller i udviklingen af de velkendte SOLID-principper (man kan sige, han er skaberen). Jeg vil også tilføje, at det var min teamleder med over 15 års erfaring, der anbefalede denne bog til mig.
Om bogen
Afhængigheder
Før jeg læste bogen, havde jeg læst en del artikler på samme måde som Habr, hvor ordet 'afhængighed' ofte optrådte. Hvad betyder det, hvem afhænger af hvem, hvad betyder det konkret at 'afhænge', og hvordan kan en klasse være afhængig af en anden?
Og mens jeg læste bogen, lærte jeg to ting:
Afhængighed — det er et term, der betyder, at en klasse (komponent, service) kender til en anden klasse (komponent, service), og denne viden er på kode niveau bestemt (nu vil java-udviklere, C#-udviklere og C-udviklere forstå mig) af en bestemt import af navnerummet. Med andre ord: hvis du har klasse A med navnerummet Default.Classes og klasse B som Another.Classes. Så, hvis der i kildekoden til klasse A optræder using Another.Classes; — så betyder det, at klasse A afhænger af klasse B.
For at forstå på diagrammet, hvor den afhængige klasse er, og hvor den ikke er — se på retningen af pilen: i 1) vil pilen pege fra klasse A mod klasse B. Det betyder, at klasse B er mere uafhængig end klasse A. Og ændringer i klasse A vil ikke påføre klasse B noget 'tab'.
SOLID
En af de vigtigste grunde til, at jeg læste denne bog, var forklaringen af SOLID-principperne fra den oprindelige kilde, fordi onkel Bob udviklede disse principper, og man kan sige, at det er takket være ham, at vi hører dette navn — SOLID.
For dem, der ikke er bekendt med det — disse principper siger, at man bør designe sine applikationer i overensstemmelse med de 5 regler:
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)
Alle disse principper kan anvendes på niveauet for klasser og objekter, på niveauet for moduler og komponenter og på niveauet for lag (tjenester).
Hvis du mener, at Single responsibility principle handler om, at en klasse eller et modul kun skal gøre én ting — så skal du bestemt læse i det mindste kapitlet om SOLID. For den definition, der gives ovenfor — er det en konsekvens, men på ingen måde en definition af selve princippet.
Om Dependency Inversion
Jeg vil gerne lægge særlig vægt på forklaringen af Dependency Inversion Principle (det, som er D i SOLID). Mens jeg læste bogen, indså jeg, at det ikke bare er et princip, men også en mekanisme og et værktøj, som du kan bruge til at ændre retningen af dine afhængigheder, og gøre for eksempel forretningslogik (DOMAIN) uafhængig af detaljerne i implementeringen af Data access layer (DAL).
Selvom selve princippet sammen med de andre i SOLID betyder noget lidt andet end mekanismen, anvendes denne mekanisme gennem hele bogen, og det er en af de grundlæggende metoder til at invertere og ændre retningen af dine afhængigheder, som for øvrigt anvendes ved DDD.
Om at træffe arkitektoniske beslutninger.
Meget ofte vil bogen nævne princippet om at træffe vigtige arkitektoniske beslutninger: om hvilken database der skal bruges, hvilket framework der skal anvendes, hvilken bibliotek der skal tilsluttes, hvad der skal bruges som søgemaskine osv.
Forfatteren mener: du skal træffe så FÅ af den slags beslutninger som muligt. For kravene kan ændre sig, begrænsningerne i ydeevnen kan også ændre sig, og den adfærdsmæssige komponent har en tendens til at ændre sig. I udviklingsprocessen kan en bestemt løsning vise sig at være mindre effektiv end en anden, mindre bekvem end en anden. Og styrken i din arkitektur vil bestemme, hvor hurtigt og smertefrit du kan erstatte en teknologi med en anden (det er faktisk noget, OCP understreger).
For eksempel kan du pludselig beslutte at bruge MongoDB i stedet for PostgreSQL, eller blot filer, eller bruge mock-data, som operationer vil blive udført i hukommelsen. Og under visse betingelser — kan dette tvinge dig til at skrive næsten hele logikken om.
For avoiding such situations, we can use certain mechanisms that will push the decision-making time as far as possible. One of these mechanisms is abstraction.
References to DDD
DDD — Domain Driven Design — is an approach to developing services with complex business logic that is critical to changes, aimed at ensuring maximum understanding among project leadership (PMs, Sale managers, etc.) and regular team members. This means that there should be a ubiquitous language among all project members, enabling everyone to understand one another and to think within the same domain with the same business rules.
If you are an advocate of DDD, or want to become one, or even if you don’t understand it but wish to, this book is a must-read, especially the second part.
Here, the author explains the existence of the Dependency Rule and why adhering to it will lead you to build the correct application architecture. It clarifies why dependencies should point towards high-level policy components. domæne (High Policy component) should be independent of the infrastructure and how this will simplify your deployment and development.
Abstraction
Uncle Bob also discusses how implementation details can harm your system and prevent it from evolving painlessly in the future.
Remember!
The database is an implementation detail.
Clients (Web, Mobile, etc.) are implementation details.
Frameworks are implementation details.
One must abstract from all of this as much as possible and not be dependent, using the above-described Dependency Inversion with interfaces and abstractions, the Dependency Rule, and other mechanisms.
Methods of building modules
I particularly enjoyed this section as a developer of services on ASP .NET CORE. Here, methodologies for constructing a unified service architecture from ready components are discussed.
Robert outlined four possible schemes for layer separation.
He made it clear why the commonly used three-layer architecture mechanism: UI (controllers), Services (Domain), DAL (Database) is quite poor compared to others. I’ve seen not many projects, but in each, for instance, a microservice on the backend, the three-layer architecture is used.
Derudover anvendes architekturen én-komponent-én-tjeneste ofte. Generelt er de begge okay, men den har en del ulemper sammenlignet med, hvordan arkitekturen opbygges ved brug af DDD, især ved kritiske ændringer og komplekse tjenester.
Alt i alt er denne anmeldelse af bogen nu ved vejs ende. Jeg har virkelig nydt bogen og fortryder ikke, at jeg læste den, tak til forfatteren. Til dig, kære læser, tak for din opmærksomhed, døm ikke for hårdt - denne publikation er baseret på mine indtryk fra bogen og mit personlige engagement.
Kilde: habr.com
