Analizzare un'applicazione e identificare i limiti per la scomposizione

Completato

Per spostare l'applicazione in un'architettura di microservizi, Fabrikam deve valutare l'applicazione corrente e determinare l'ambito e i limiti di ogni microservizio. Per questa valutazione, verrà usato il framework di progettazione basata su domini. Si vedrà ora come usarlo per l'applicazione.

Nota

Questo articolo non contiene un'analisi dei domini completa ed esaustiva. I concetti sono volutamente sintetizzati per illustrare i punti principali. Per altre informazioni sulla progettazione basata su domini, vedere la sezione "Altre informazioni" alla fine di questo modulo.

Che cos'è la progettazione basata su domini?

La progettazione basata su domini è un approccio alla progettazione di sistema introdotto originariamente da Erik Evans nel libro del 2005 Domain-Driven Design: Tackling Complexity in the Heart of Software. Questo approccio include tre elementi chiave:

• Esaminare il dominio principale e la logica del dominio.
• Strutturare la progettazione in base a un modello del dominio.
• Favorire la collaborazione iterativa tra team tecnici e partner aziendali per migliorare continuamente il sistema.

La progettazione basata su domini offre un framework che agevola la creazione di microservizi ben progettati e prevede due fasi distinte, quella strategica e quella tattica. Nella progettazione strategica si definisce la struttura su larga scala del sistema. La progettazione strategica garantisce che l'architettura rimanga incentrata sulle funzionalità aziendali. La progettazione tattica offre un set di schemi progettuali che è possibile usare per creare il modello di dominio. Questi schemi includono entità, aggregazioni e servizi di dominio. Gli schemi tattici consentono di progettare microservizi a regime di controllo libero e coesi.

Durante la fase strategica della progettazione basata su domini, si esegue il mapping del dominio aziendale e si definiscono i contesti delimitati per i modelli di dominio. La progettazione basata su domini tattica consente di definire i modelli di dominio con maggiore precisione. Gli schemi tattici vengono applicati all'interno di un singolo contesto delimitato. In un'architettura di microservizi gli elementi più interessanti sono costituiti dagli schemi di aggregazione ed entità. L'applicazione di questi schemi consente di identificare i limiti naturali dei servizi nell'applicazione. In linea generale, un microservizio non deve essere più piccolo di un'aggregazione e non deve essere più grande di un contesto delimitato.

A livello generale, è possibile suddividere questo processo in quattro passaggi:

1. Analizzare il dominio aziendale per comprendere i requisiti funzionali dell'applicazione. L'output di questo passaggio è una descrizione informale del dominio, che può essere successivamente perfezionata in un set più formale di modelli di dominio.
2. Definire i contesti delimitati del dominio. Ogni contesto delimitato contiene un modello di dominio che rappresenta un sottodominio specifico dell'applicazione principale.
3. All'interno di un contesto delimitato applicare gli schemi di progettazione basata su domini tattica per definire entità, aggregazioni e servizi di dominio.
4. Identificare i microservizi nell'applicazione usando i risultati del passaggio precedente.

Si esaminerà ora in maggiore dettaglio cosa succede in ognuno di questi passaggi.

Analizzare il dominio aziendale

La progettazione basata su domini inizia dalla modellazione del dominio aziendale e dalla creazione di un modello di dominio. Il modello di dominio è un modello astratto del dominio aziendale. Estrae e organizza le informazioni sul dominio e offre un linguaggio comune per sviluppatori ed esperti di dominio.

Per iniziare, eseguire un mapping di tutte le funzioni aziendali con le relative connessioni. Questa analisi è un impegno collaborativo che coinvolge esperti di settore, architetti software e altri stakeholder. Non è necessario usare un formalismo particolare. Tracciare un diagramma o un disegno su una lavagna.

Man mano che si compila il diagramma, si potranno identificare i sottodomini discreti. Quali funzioni sono strettamente correlate? Quali funzioni sono essenziali per l'azienda e quali forniscono servizi ausiliari? Che cos'è il grafo delle dipendenze? Durante questa fase iniziale, non è necessario preoccuparsi delle tecnologie o dei dettagli di implementazione. Ciò premesso, sarà necessario stabilire la posizione in cui l'applicazione dovrà integrarsi con i sistemi esterni, ad esempio i sistemi CRM, di elaborazione dei pagamenti o di fatturazione.

Definire i contesti delimitati

Il modello di dominio include rappresentazioni di elementi del mondo reale, ad esempio utenti, droni e pacchetti. Questo non significa tuttavia che ogni parte del sistema debba usare le stesse rappresentazioni per gli stessi elementi.

Ad esempio, i sottosistemi che gestiscono la riparazione dei droni e l'analisi predittiva devono rappresentare molte caratteristiche fisiche dei droni. Queste caratteristiche includono la cronologia della manutenzione, il chilometraggio, età, numero di modello e dettagli delle prestazioni. Quando si tratta di pianificare una consegna, questi elementi non sono importanti. Il sottosistema di pianificazione deve solo sapere se un drone è disponibile o meno e il tempo stimato di arrivo per il ritiro e la consegna.

Il tentativo di creare un unico modello per entrambi i sottosistemi risulterà più complesso del necessario. e l'evoluzione del modello nel tempo potrebbe essere compromessa perché qualsiasi modifica dovrà soddisfare più team che lavorano su sottosistemi distinti. Spesso è meglio progettare modelli separati che rappresentano la stessa entità del mondo reale, in questo caso un drone, in due contesti diversi. Ogni modello contiene solo le funzionalità e gli attributi pertinenti per il contesto specifico.

Con questo approccio entra in gioco il concetto di contesti delimitati della progettazione basata su domini. Un contesto delimitato è semplicemente un limite all'interno di un dominio a cui si applica un modello di dominio specifico. Osservando il diagramma precedente, è possibile raggruppare le funzionalità in base al fatto che le varie funzioni condividano o meno un singolo modello di dominio.

Definire entità, aggregazioni e servizi

La progettazione basata su domini tattica consente di definire i modelli di dominio con maggiore precisione. Gli schemi tattici vengono applicati all'interno di un singolo contesto delimitato. In un'architettura di microservizi gli elementi più interessanti sono costituiti dagli schemi di aggregazione ed entità. L'applicazione di questi schemi consente di identificare i limiti naturali dei servizi nell'applicazione. In linea generale, un microservizio non deve essere più piccolo di un'aggregazione e non deve essere più grande di un contesto delimitato.

Sono disponibili diversi modelli di progettazione basata su domini tattica:

• Entità: Un'entità è un oggetto con un'identità univoca che persiste nel tempo. Ad esempio, in un'applicazione bancaria i clienti e i conti sono entità.
• Oggetti valore: Un oggetto valore non ha identità. I valori dei relativi attributi lo definiscono ed è non modificabile. Alcuni esempi tipici di oggetti valore sono i colori, le date e ore e i valori di valuta.
• Aggregazioni: Un'aggregazione definisce un limite di coerenza per una o più entità. Lo scopo di un'aggregazione è la modellazione di invarianti transazionali. Gli elementi nel mondo reale hanno reti di relazioni complesse. I clienti creano gli ordini, gli ordini contengono prodotti, i prodotti hanno fornitori e così via. Se l'applicazione modifica diversi oggetti correlati, come può garantire la coerenza? Come si tiene traccia delle invarianti e come vengono imposte?
• Servizi di dominio e servizi dell'applicazione: Nella terminologia della progettazione basata su domini un servizio è un oggetto che implementa una logica senza bloccare uno stato. Evans distingue tra servizi di dominio che incapsulano la logica del dominio e servizi dell'applicazione che offrono funzionalità tecniche. I servizi dell'applicazione in genere includono funzionalità tecniche come l'autenticazione utente o l'invio di un messaggio SMS. I servizi di dominio vengono spesso usati per modellare il comportamento che si estende su più entità.
• Eventi del dominio: Gli eventi del dominio consentono di comunicare ad altre parti del sistema quando si verifica un evento. Come suggerito dal nome, gli eventi di dominio indicano qualcosa che accade all'interno del dominio. Ad esempio "un record è stato inserito in una tabella" non è un evento di dominio. "Una consegna è stata annullata" è invece un evento di dominio. Gli eventi di dominio sono particolarmente importanti in un'architettura di microservizi. Poiché i microservizi sono distribuiti e non condividono archivi dati, gli eventi di dominio consentono ai microservizi di coordinarsi tra loro.

Nel proprio sistema il team di sviluppo di Fabrikam ha identificato le entità seguenti:

• Consegna
• Pacchetto
• Drone
• Conto
• Conferma
• Notifica
• Tag

Le prime quattro, ovvero consegna, pacchetto, drone e account, sono tutte aggregazioni che rappresentano limiti di coerenza transazionali. Le conferme e le notifiche sono entità figlio delle consegne e le etichette sono entità figlio dei pacchetti.

Gli oggetti valore in questa progettazione includono l'indirizzo, l'ora stimata per ritiro e consegna, il peso del pacchetto e le dimensioni del pacchetto.

Sono presenti due eventi di dominio:

• Mentre un drone è in volo, l'entità drone invia eventi DroneStatus che descrivono la posizione del drone e il relativo stato, ad esempio in volo o atterrato.
• L'entità recapito invia eventi DeliveryTracking ogni volta che cambia la fase di una consegna. Alcuni valori sono DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff e DeliveryCompleted.

Si noti che questi eventi descrivono elementi che risultano significativi all'interno del modello di dominio. Offrono informazioni sul dominio e non sono legati a un costrutto di linguaggio di programmazione specifico.

Il team di sviluppo ha identificato un'altra area di funzionalità, che non rientra perfettamente nelle entità descritte finora. Alcune parti del sistema devono coordinare tutte le fasi coinvolte nella pianificazione o nell'aggiornamento di una consegna. Il team di sviluppo ha aggiunto due servizi di dominio alla progettazione. Un'utilità di pianificazione coordina i passaggi. Un supervisore monitora lo stato di ogni passaggio, al fine di verificare se sono presenti passaggi con esito negativo o scaduti.

Identificare i microservizi

Ora è possibile passare dal modello di dominio alla progettazione dell'applicazione. Di seguito è riportato un approccio che è possibile usare per derivare i microservizi dal modello di dominio.

1. Iniziare con un contesto delimitato. In generale, la funzionalità di un microservizio non dovrebbe estendersi a più di un contesto delimitato. Un contesto delimitato segna per definizione il limite di un modello di dominio specifico. Se il microservizio combina modelli di dominio diversi, può essere necessario perfezionare l'analisi del dominio.
2. Esaminare quindi le aggregazioni nel modello di dominio. Le aggregazioni sono spesso buoni candidati per i microservizi. Un'aggregazione ben progettata mostra molte delle caratteristiche di un microservizio ben progettato:
   • Un'aggregazione deriva da requisiti aziendali piuttosto che da considerazioni di tipo tecnico, ad esempio l'accesso ai dati o la messaggistica.
   • Un'aggregazione deve avere un'elevata coesione funzionale.
   • Un'aggregazione è un limite di persistenza.
   • Le aggregazioni devono essere a regime di controllo libero.
3. I servizi di dominio sono anche candidati ottimali per i microservizi. I servizi di dominio sono operazioni senza stato tra più aggregazioni. Un esempio tipico è un flusso di lavoro che coinvolge diversi microservizi. Più avanti vedremo un esempio di servizio di dominio nell'applicazione Drone Delivery.
4. Tenere conto, infine, dei requisiti non funzionali. Esaminare alcuni fattori, ad esempio dimensioni del team, tipi di dati, tecnologie, requisiti di scalabilità, requisiti di disponibilità e requisiti di sicurezza. Questi fattori possono indurre a scomporre ulteriormente un microservizio in due o più servizi più piccoli oppure a effettuare l'operazione inversa, riunendo più microservizi in uno.

È importante essere pragmatici e ricordare che la progettazione basata su domini è un processo iterativo. In caso di dubbi, iniziare con microservizi con granularità grossolana. Suddividere un microservizio in due servizi più piccoli è più facile che effettuare il refactoring delle funzionalità tra più microservizi esistenti.

Applicare la progettazione basata su domini all'applicazione di gestione dei droni

Per l'applicazione di Fabrikam, tutti i servizi si trovano nell'applicazione monolitica esistente. Dopo aver stabilito dove è possibile scomporre l'applicazione in microservizi, il team inizierà con il servizio di gestione dei pacchetti.

Il servizio di gestione dei pacchetti ha attualmente un team di sviluppo dedicato, presenta problemi di prestazioni correlati alla scalabilità ed è un ottimo candidato per iniziare a scomporre l'applicazione.