Domain-driven design (DDD): microservizi, quanto devono essere grandi?

L’utilizzo dei Microservizi nella creazione delle nuove applicazioni è un trend che si sta sempre più affermando tra i team di sviluppo che adottano metodologia agile e che oggi devono ingegnerizzare il software in modo da poter sfruttare al meglio le risorse in cloud.

Il disegno delle applicazioni a Microservizi, ossia attraverso l’interconnessione di più servizi capaci di svolgere specifiche funzioni, è infatti in grado di rendere più agili i processi di sviluppo, aggiornamento e test (per parti) dei sistemi più complessi.

Il vantaggio non risiede soltanto nella possibilità di poter sviluppare in modo indipendente componenti che in passato nelle applicazioni con struttura a monolite dovevano essere collaudate e rilasciate in blocco, ma anche nel poter differenziare l’ambiente di esecuzione tra on premise, cloud pubblico o privato in funzione delle esigenze di costo o sicurezza. Con i Microservizi è inoltre possibile reimpiegare le funzioni in applicazioni diverse, offrire le funzioni all’esterno a clienti e partner, e sfruttarle come mattoni costitutivi per applicazioni nuove riducendo i tempi di sviluppo.

Lo sviluppo a Microservizi necessita, a monte, di un’efficace segmentazione delle esigenze applicative in servizi indipendenti e il più possibile riutilizzabili.

Gli approcci per la definizione dei Microservizi

Lo sviluppo a Microservizi non sfugge dalle regole generali che oggi suggeriscono l’impiego di team di sviluppo molto ridotti per garantire l’efficacia dei risultati: da due a cinque persone al massimo, secondo il concetto “two pizza‑size team” teorizzato da Jeff Bezos (secondo il vulcanico CEO di Amazon un team efficace deve potersi sfamare con due pizze).

Nello sviluppo dei Microservizi ha un ruolo importante il principio della singola responsabilità (SRP), ovvero che ogni oggetto software, così come ogni modulo di servizio creato, debba avere responsabilità su una singola funzione dell’applicazione. Un principio introdotto da Robert Cecil Martin, tra gli autori del manifesto per lo sviluppo Agile del software e punto di riferimento per l’innovazione di questo settore.

Al di là dei principi generali, un approccio che sta prendendo piede per la creazione di Microservizi è il Domain‑Driven Design, spesso abbreviato con l’acronimo DDD, e che si è rivelato molto valido per affrontare le complessità dei sistemi distribuiti. Nel DDD assume grande importanza l’individuazione e la segmentazione dei “Bounded Context” ossia dei contesti limitati entro i quali è opportuno fissare i confini di ciascun servizio. DDD aiuta, inoltre, a creare una fattiva collaborazione tra gli esperti del dominio applicativo e gli sviluppatori, in modo che sia possibile definire per approssimazioni successive il modello concettuale dei servizi utile a risolvere gli specifici problemi.

Sviluppare Microservizi: i vantaggi dell’approccio di Domain‑Driven Design

Domain‑Driven Design (DDD) è un approccio allo sviluppo del software teorizzato da Eric Evans (e spiegato nel libro “Domain‑Driven Design: Tackling Complexity in the Heart of Software”) per affrontare problemi complessi attraverso il collegamento dell’implementazione con un modello in evoluzione. Applicato ai Microservizi, DDD aiuta a centrare gli obiettivi del progetto su aspetti chiave per la logica applicativa, quindi a fondare lo sviluppo su entità che hanno un effettivo senso funzionale.

L’approccio DDD si realizza riportando nell’implementazione le assunzioni del Bounded Context, ossia le definizioni esplicite del contesto di applicazione del modello, che comprendono i punti dell’applicazione in cui viene usato e i confini a livello dell’organizzazione.

Questo approccio consente di mantenere coerente nel tempo il modello, evitando influenze da parte dell’ecosistema che sta intorno.

Il DDD aiuta a evitare rischi di frammentazioni eccessive del modello, che comportano problemi d’integrazione e di coerenza delle informazioni. Per questo, comprende una serie di principi atti ad aiutare gli sviluppatori a integrare il codice e svolgere i test condividendo le idee per guidare l’evoluzione del modello. DDD aiuta, inoltre, a creare connessioni tra contesti applicativi diversi e gestire l’inclusione di servizi già esistenti, non nati con logica object oriented.

Un ambito significativo di impiego del DDD riguarda la capacità di riutilizzare software legacy. In un White Paper dal titolo “Getting started with DDD when surrounded by legacy system” Eric Evans spiega nel dettaglio le possibili modalità per sfruttare in modo efficace l’approccio DDD nella modernizzazione delle applicazioni esistenti.

I 10 punti per definire correttamente i Microservizi

L’esperienza sul campo suggerisce di raccogliere i seguenti elementi per definire i confini di un Microservizio:

1. Cosa deve fare (funzioni e responsabilità dell’entità) e qual è il ruolo nella struttura dell’applicazione.
2. Come comunica con gli altri Microservizi.
3. Quale tecnologia usa (è possibile impiegare linguaggi e framework diversi, alcuni più adatti di altri per specifiche funzioni).
4. Requisiti per ciascuna funzione (performance e accessibilità).
5. Esigenze di isolamento tra servizi statici (che non cambiano nel tempo) e servizi con evoluzioni frequenti (lo scopo è per ridurre le componenti coinvolte nei cambiamenti).
6. Esigenze di isolamento tra funzioni critiche e non critiche (per non propagare gli eventuali problemi).
7. Esigenze di isolamento tra servizi che hanno cicli di vita indipendenti (commit del codice, per poter testare con frequentemente le funzioni).
8. Esigenze di isolamento per servizi che dipendono da funzioni esterne (così da evitare che si debba arrestare l’intera applicazione).
9. Raggruppamenti di funzionalità interdipendenti.
10. Sicurezza: come isolare le funzioni che gestiscono o elaborano dati sensibili.

Indipendentemente dall’approccio scelto per la definizione dei Microservizi, l’attenzione ai requisiti funzionali, agli aspetti strutturali dell’applicazione e alle competenze da mettere in gioco sono le chiavi per il successo del progetto.

Scopri i 5 libri sulle architetture a microservizi che dovresti leggere e le 7 buone pratiche per scrivere microservizi!