Questa sarà una narrazione sull'impressione di un libro, e verranno considerati 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 abbastanza incertezze in questo termine. E sembra tutto chiaro, ma è anche in un certo senso astratto e privo di precisione. Martin ritiene, e io concordo con lui, che un'applicazione abbia due componenti:
- Comportamento (behavior) — funzioni e compiti che il programma (componente, servizio) svolge.
- Architettura — questo termine riguarda in maggior misura la modifica dell'applicazione.
Ma anche se l'applicazione svolge molto bene il compito che deve eseguire, ciò non significa affatto 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 dello sviluppo. L'architettura riguarda la velocità con cui la comprensione arriva a una nuova persona nel team.
Ecco come costruire questa architettura, come liberarsi del mal di testa riguardo a piccole modifiche dei requisiti da parte del PM o di un stakeholder: di questo parlerà il libro.
A proposito degli autori
Prima di dire qualcosa su questo libro, voglio dire un po' su di me.
Attualmente sono un Strong Junior Developer, specializzato nello sviluppo di servizi tramite ASP .NET CORE.
Lavoro già da un anno in una 'galleria' e sembra che me la cavi poco a poco.
Ho già letto questo libro 2 volte e lo consiglio a tutti:
- sviluppatori di sistemi embedded;
- front-end developers;
- back-end developers;
- e anche DevOps.
In generale, a chiunque abbia qualche legame con lo sviluppo del software, intendo lo sviluppo diretto di varie cose, qui non includiamo Sales e PM (anche se sarebbe utile sapere perché un dev può impiegare il doppio del tempo per un compito), consiglio di leggere questo libro.
E ora cercherò di argomentare perché la penso così.
Un po' sull'autore di questo libro (perché per me l'autorità di chi scrive gioca un ruolo importante). Penso che mi capirete; anche se non è sempre corretto, se vi parla una persona di autorità nel settore, riponete molto più fiducia in ciò che dice. Ad esempio, penso che crederete di più a una diagnosi formulata dal vostro medico piuttosto che a quella di una persona qualsiasi nella folla (che ha cercato i sintomi su Google).
Robert Martin, noto anche come Uncle Bob (zio Bob), lavora nel campo della programmazione, in vari sistemi (dai servizi web ai sistemi embedded), dal 1970. È un consulente tecnico e architetto, ha scritto per vari periodici tecnici ed è un programmatore molto esperto, nonché una persona che ha avuto uno dei ruoli chiave nella creazione dei ben noti principi SOLID (si può dire sia il creatore). Vorrei anche aggiungere che questo libro mi è stato consigliato dal mio team leader con oltre 15 anni di esperienza.
Sul libro
Dipendenze
Prima di leggere il libro, ho letto molte articoli sullo stesso Habr, dove veniva spesso citata la parola "dipendenza". Cos'è, chi dipende da chi, cosa significa esattamente "dipendere", e come può un certo classe dipendere da un'altra?
E così, mentre leggevo il libro, ho appreso due concetti:
La dipendenza è un termine che significa che una certa classe (componente, servizio) è a conoscenza di un'altra classe (componente, servizio), e questa conoscenza, a livello di codice, è definita (ora i programmatori Java, C# e C lo capiranno) da un certo import del namespace. In altre parole: avete la classe A con namespace Default.Classes e la classe B Another.Classes. Ecco, se nel codice sorgente della classe A compare using Another.Classes; — questo 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: nella 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 causeranno alcun "danno" alla classe B.
SOLID
Una delle principali ragioni che mi hanno spinto a leggere questo libro è stata la spiegazione dei principi SOLID dalla fonte originale, perché zio Rob ha sviluppato questi principi e si può dire che grazie a lui sentiamo questo nome — SOLID.
Per coloro che non lo sanno, questi principi suggeriscono di progettare le proprie applicazioni secondo 5 regole:
S — SRP (Principio di Responsabilità Unica)
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 layer (servizi).
Se pensate che il Principio di Responsabilità Unica significhi che una classe o un modulo debba fare solo una cosa, dovete assolutamente leggere almeno il capitolo su SOLID. Questa definizione è una conseguenza, ma non la definizione del principio stesso.
Sull'Inversione delle Dipendenze
Voglio attirare l'attenzione sulla spiegazione del Principio di Inversione delle Dipendenze (quella che è la D di SOLID). Durante la lettura del libro, ho capito che non è solo un principio, ma anche un meccanismo e uno strumento, grazie al quale potete cambiare la direzione delle vostre dipendenze e rendere, ad esempio, la logica di business (DOMAIN) indipendente dai dettagli di implementazione del livello di accesso ai dati (DAL).
Anche se il principio stesso, insieme agli altri di SOLID, significa un po' diverso dal meccanismo, questo meccanismo è utilizzato per tutta la durata del libro ed è uno dei principali metodi per invertire e cambiare la direzione delle vostre dipendenze, che è anche usato nel DDD.
Sulla presa di decisioni architetturali
Spesso nel libro verrà menzionato un principio riguardante la presa di decisioni architetturali importanti: quale database utilizzare, quale framework adottare, quale libreria integrare, quale motore di ricerca utilizzare, ecc.
Quindi, l'autore ritiene che dobbiate prendere il MINOR numero possibile di tali decisioni. Perché i requisiti possono cambiare, i limiti delle performance anche, e la componente comportamentale tende a cambiare. Durante il processo di sviluppo, una certa decisione può apparire meno efficace rispetto a un'altra, meno conveniente rispetto a un'altra. E la forza della vostra architettura definirà quanto rapidamente e senza dolore riuscirete a sostituire una tecnologia con un'altra (su questo, tra l'altro, insiste l'OCP).
Ad esempio, improvvisamente potreste decidere di utilizzare MongoDb al posto di Postgresql, o addirittura file, o utilizzare dati mockati, le cui operazioni verranno eseguite in memoria. E in alcune condizioni, questo potrebbe richiedere di riscrivere quasi tutta la logica.
Per evitare che si verifichino situazioni del genere, possiamo utilizzare alcuni meccanismi che ritardano 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 logiche di business complesse, critiche ai cambiamenti, volto a massimizzare la comprensione delle posizioni di leadership del progetto (PM, responsabili vendite, ecc.), insieme ai membri del team. In altre parole, per fare in modo che tra tutti i membri del progetto ci sia un linguaggio comune e che ognuno possa comprendere l'altro, in modo che tutti pensino all'interno di un dominio con le stesse regole di business.
Se siete sostenitori di DDD, o desiderate esserlo, o se non comprendete qualcosa in merito ma volete capire — il libro è una lettura obbligatoria, soprattutto la seconda parte del libro.
Qui l'autore spiega l'esistenza della Dependency Rule e perché, seguendola, costruirete un'architettura corretta per l'applicazione. Perché le dipendenze devono rivolgersi verso i componenti di High Policy. dominio (High Policy component) deve essere indipendente dall'infrastruttura e come questo semplificherà il vostro deployment e sviluppo.
Astrazione
Zio Rob parla anche di come i dettagli di implementazione possano danneggiare il vostro sistema e impedirne l'evoluzione senza dolori in futuro.
Ricordate!
Il DB è un dettaglio di implementazione.
I clienti (Web, Mobile, ecc.) sono dettagli di implementazione.
I framework sono dettagli di implementazione.
Da tutto ciò bisogna massimizzare l'astrazione e non dipendere, utilizzando la Dependency Inversion sopra descritta con interfacce e astratti, la Dependency Rule e altri meccanismi.
Metodi di costruzione dei moduli
Questa sezione mi è piaciuta particolarmente come sviluppatore di servizi su ASP .NET CORE. Infatti, qui si parla di metodologie per costruire un'architettura unitaria del servizio a partire da componenti pronti.
Robert ha descritto 4 possibili schemi di separazione dei livelli.
Ha chiarito perché il meccanismo spesso utilizzato dell'architettura a 3 livelli: UI (controller), Servizi (Dominio), DAL (Database) — sia piuttosto scadente rispetto ad altri. Ho visto pochi progetti, ma in ognuno, ad esempio in un microservizio nel backend, viene utilizzata appunto l'architettura a tre livelli.
Inoltre, abbastanza spesso, viene utilizzata l'architettura uno-componente-uno-servizio. In generale, entrambe sono valide, ma ha abbastanza svantaggi rispetto a come viene costruita, per esempio, l'architettura utilizzando il DDD, soprattutto nei servizi critici per le modifiche e complessi.
In sintesi, si conclude questa recensione del libro. Il libro stesso mi è piaciuto molto, non mi pento di averlo letto, grazie all'autore. A voi, cari lettori, grazie per l'attenzione, non giudicate severamente — questa pubblicazione si basa sulle impressioni del libro e sul mio personale entusiasmo.
Fonte: habr.com
