Questa sarà una narrazione delle impressioni sul libro, oltre a esplorare alcuni concetti e conoscenze che grazie a questo libro sono stati appresi.
Architettura
Puoi, leggendo questa pubblicazione, dare una risposta chiara alla domanda: che cos'è l'architettura? Che cos'è l'architettura nel contesto della programmazione e del design? Qual è il suo ruolo? Ci sono molte ambiguità in questo termine. E sembra che sia tutto chiaro, ma in un modo astratto e senza precisione. Martin sostiene, e io sono d'accordo con lui, che un'applicazione ha due componenti:
- Comportamento (behavior) — le funzioni e i compiti che il programma (componente, servizio) esegue.
- L'architettura — questo termine riguarda maggiormente la modifica dell'applicazione.
Ma anche se l'applicazione svolge molto bene il compito per cui è stata progettata, questo non significa che abbia una buona architettura. L'architettura non riguarda il comportamento dell'applicazione. L'architettura riguarda la facilità di modifica, l'architettura riguarda la facilità di distribuzione, l'architettura riguarda l'indipendenza nello sviluppo. L'architettura riguarda la velocità con cui la comprensione arriva a una nuova persona nel team.
Ecco come costruire questa architettura, come liberarsi dal mal di testa quando ci sono piccole modifiche alle richieste del PM o dello stakeholder: di questo parla il libro.
Chi siamo
Prima di dire qualcosa su questo libro, voglio dire un po' di me.
Attualmente sono un Strong Junior Developer, specializzato nello sviluppo di servizi con ASP .NET CORE.
Lavoro già da un anno in una "galleria" e sembra che stia gestendo tutto poco a poco.
Ho già letto questo libro due volte e lo consiglio a tutti:
- sviluppatori di sistemi embedded;
- front-end developer;
- back-end developer;
- e persino devops.
Insomma, a chiunque sia coinvolto nello sviluppo software, intendo direttamente nello sviluppo, escludendo vari Sales e PM (anche se sarebbe utile sapere perché un dev può spendere il doppio del tempo su un compito), consiglio di leggere questo libro.
Ora cercherò di argomentare perché la penso così.
Un po' sull'autore di questo libro (perché per me l'autorità di chi scrive conta molto). Penso che mi capirete, anche se non sempre è giusto; ma se qualcuno di autorità nel settore vi dice qualcosa, mostrate certamente maggiore fiducia in ciò che afferma. Ad esempio, penso che vi fidiate di più della diagnosi che vi fa un medico piuttosto che di quella di una persona a caso (che ha cercato su Google i sintomi).
Robert Martin, conosciuto anche come Uncle Bob, lavora nel campo della programmazione, in diverse aree (dai servizi web ai sistemi embedded), dal 1970. È consulente tecnico e architetto, ha scritto per varie riviste tecniche, è un programmatore molto esperto e una persona che ha giocato un ruolo chiave nella creazione dei noti principi SOLID (si può dire che sia il creatore). Vorrei anche aggiungere che questo libro mi è stato consigliato dal mio team leader con oltre 15 anni di esperienza.
Info sul libro
Dipendenze
Prima di leggere il libro, ho letto diversi articoli simili su Habr, dove si parlava di una parola come "dipendenza". Che cos'è, chi dipende da chi, cosa significa esattamente "dipendere" e come può un certo classe dipendere da un'altra?
E mentre leggevo il libro ho acquisito due concetti:
La dipendenza è un termine che significa che una certa classe (componente, servizio) è consapevole di un'altra classe (componente, servizio), e questa conoscenza a livello di codice è definita (ora gli sviluppatori Java, C# e C possono capirmi) da un determinato import di namespace. In altre parole: avete una classe A con namespace Default.Classes e una classe B Another.Classes. Se nel codice sorgente della classe A appare using Another.Classes; — significa che la classe A dipende dalla classe B.
Per capire nello schema dove si trova la classe dipendente e dove no — guardate la direzione della freccia: in 1) la freccia punta dalla classe A verso la classe B. Questo significa che la classe B è più indipendente della classe A. E le modifiche nella classe A non arrecheranno alcun "danno" alla classe B.
SOLID
Una delle principali ragioni che mi ha spinto a leggere questo libro è la spiegazione dei principi SOLID dalla fonte originale, poiché zio Bob ha sviluppato questi principi e si può dire che grazie a lui sentiamo questo nome: SOLID.
Per chi non lo sapesse, questi principi suggeriscono di progettare le proprie applicazioni seguendo 5 regole:
S — SRP (Principio di responsabilità singola)
O — OCP (Principio aperto-chiuso)
L — LSP (Principio di sostituzione di Liskov)
I — ISP (Principio di segregazione delle interfacce)
D — DIP (Principio di inversione delle dipendenze)
Tutti questi principi possono essere applicati a livello di classi e oggetti, a livello di moduli e componenti e a livello di strati (servizi).
Se pensate che il Principio di responsabilità singola significhi che una classe o un modulo debba fare solo una cosa, dovete assolutamente leggere almeno il capitolo sui SOLID. Perché quella definizione fornita sopra è una conseguenza, ma non è affatto la definizione del principio stesso.
Sull'inversione delle dipendenze
Vorrei porre particolare attenzione sulla spiegazione del Dependency Inversion Principle (quello che è la D di SOLID). Leggendo il libro, ho capito che non è solo un principio, ma anche un meccanismo e uno strumento attraverso cui puoi cambiare la direzione delle tue dipendenze, rendendo, ad esempio, la logica di business (DOMAIN) indipendente dai dettagli di implementazione del Data Access Layer (DAL).
Anche se il principio stesso, insieme agli altri di SOLID, significa qualcosa di diverso rispetto al meccanismo, quest'ultimo viene utilizzato per tutto il libro ed è uno dei metodi principali per invertire e cambiare la direzione delle tue dipendenze, che tra l'altro è impiegato nel DDD.
Sulle decisioni architetturali
Molto spesso, nel libro verrà menzionato il principio riguardante l'adozione di decisioni architetturali importanti: quale database utilizzare, quale framework scegliere, quale libreria integrare, cosa utilizzare come motore di ricerca, ecc.
Così, l'autore sostiene: dovresti prendere decisioni di questo tipo il più raramente possibile. Infatti, i requisiti possono cambiare, le limitazioni delle performance anche, e la componente comportamentale tende a modificarsi. Durante il processo di sviluppo, una certa decisione può apparire meno efficace rispetto ad un'altra, o meno comoda rispetto ad un'altra. La solidità della tua architettura determinerà quanto rapidamente e senza problemi sarai in grado di sostituire una tecnologia con un'altra (questo è ciò che ribadisce l'OCP).
Ad esempio, all'improvviso, potresti decidere di utilizzare MongoDB al posto di PostgreSQL, o addirittura file, o utilizzare dati mockati, con cui saranno eseguite operazioni in memoria. E in alcune condizioni, ciò potrebbe costringerti a riscrivere quasi tutta la logica.
Per evitare che si verifichino situazioni di questo tipo, possiamo utilizzare alcuni meccanismi che allontanano il più possibile il momento della decisione. Uno di questi meccanismi è l'astrazione.
Riferimenti a DDD
DDD — Domain Driven Design — un approccio allo sviluppo di servizi con una logica aziendale complessa e critica ai cambiamenti, mirato a massimizzare la comprensione da parte delle figure dirigenziali del progetto (PM, Sales Manager, ecc.) e dei membri del team. Cioè, affinché tutti i membri del progetto possano avere un linguaggio comune, in modo che ciascuno possa comprendere l'altro e pensare nello stesso dominio con le stesse regole aziendali.
Se sei un sostenitore del DDD, o vuoi esserlo, o se non capisci qualcosa e desideri comprenderlo — questo libro è imperdibile, specialmente la seconda parte.
Qui l'autore spiega l'esistenza della Dependency Rule e perché, seguendola, costruirai un'architettura dell'applicazione corretta. Perché le dipendenze dovrebbero seguire la direzione verso i componenti ad alta policy, e perché un dominio (i componenti ad alta policy) dovrebbero essere indipendenti dall'infrastruttura e come questo semplificherà il tuo deployment e sviluppo.
Astrazione
Zio Rob parla anche di come i dettagli di implementazione possono danneggiare il tuo sistema e ostacolare la sua evoluzione senza difficoltà in futuro.
Ricorda!
Il database è un dettaglio di implementazione.
I clienti (Web, Mobile, ecc.) sono dettagli di implementazione.
I framework sono un elemento dell'implementazione
È fondamentale astrarsi il più possibile da tutto ciò e non dipendere da esso, utilizzando il Dependency Inversion descritto in precedenza con interfacce e astrazioni, la Dependency Rule e altri meccanismi
Metodi per la costruzione di moduli
Questo segmento mi è piaciuto particolarmente, come sviluppatore di servizi su ASP .NET CORE, perché discute le metodologie per costruire un'architettura di servizio unificata da componenti pronti all'uso.
Robert ha descritto 4 possibili schemi di separazione dei livelli.
Ha sottolineato perché il meccanismo dell'architettura a tre livelli, molto usato: UI (controller), Services (Domain), DAL (Database) — è piuttosto inefficace rispetto ad altre soluzioni. Ho visto relativamente pochi progetti, ma in ognuno, ad esempio in microservizi, viene utilizzata l'architettura a tre livelli.
Allo stesso modo, viene spesso utilizzata l'architettura uno-componente-uno-servizio. In generale, entrambe sono valide, ma presentano diverse lacune, a confronto con l'architettura basata su DDD, soprattutto in servizi critici con frequenti cambiamenti e complessità.
In definitiva, è giunto al termine questo riassunto del libro. Il libro stesso mi è piaciuto molto, non rimpiango di averlo letto, grazie all’autore. A voi, cari lettori, grazie per l'attenzione, non giudicate troppo severamente — questa pubblicazione è basata sulle impressioni del libro e sul mio entusiasmo personale.
Fonte: habr.com
