Uso dell'analisi del dominio per modellare i microservizi
Una delle principali problematiche dei microservizi consiste nel definire i limiti dei singoli servizi. La regola generale è che un servizio deve fare "una cosa", ma mettere in pratica tale regola richiede un'attenta riflessione. Non esistono processi meccanici in grado di generare la progettazione "corretta". È necessario considerare in modo approfondito il dominio aziendale, i requisiti, le caratteristiche dell'architettura (noti anche come requisiti non funzionali) e gli obiettivi. In caso contrario, si potrebbe ottenere una progettazione casuale con caratteristiche non desiderate, ad esempio dipendenze nascoste tra servizi, accoppiamento rigido o interfacce con una progettazione di bassa qualità. Questo articolo illustra un approccio basato su dominio alla progettazione di microservizi. La valutazione dei limiti del servizio è un impegno continuo per i carichi di lavoro in continua evoluzione. A volte la valutazione comporta definizioni ridefinite dei limiti esistenti che richiedono lo sviluppo di applicazioni aggiuntive per soddisfare le modifiche.
Questo articolo usa un servizio di consegna tramite drone come esempio in esecuzione. Per altre informazioni sullo scenario e sull'implementazione di riferimento corrispondente, vedere qui.
Introduzione
I microservizi devono essere progettati in base alle funzionalità aziendali e non in base a livelli orizzontali, come l'accesso ai dati o la messaggistica. Devono inoltre prevedere un accoppiamento non rigido e un'elevata coesione funzionale. I microservizi sono caratterizzati da un accoppiamento non rigido se è possibile apportare modifiche a un servizio senza dover contemporaneamente aggiornare gli altri servizi. Un microservizio è coeso se ha un unico obiettivo ben definito, ad esempio la gestione degli account utente o la traccia della cronologia di recapito. Un servizio deve incapsulare le informazioni del dominio e gestire l'astrazione di tali informazioni dai client. Un client deve ad esempio essere in grado di pianificare un drone senza conoscere i dettagli dell'algoritmo di pianificazione o la modalità di gestione della flotta di droni. Le caratteristiche dell'architettura devono essere definite per ogni microservizio in modo che corrispondano ai relativi problemi di dominio, anziché essere definite per l'intero sistema. Ad esempio, un microservizio rivolto ai clienti potrebbe dover avere prestazioni, disponibilità, tolleranza di errore, sicurezza, testabilità e agilità. Un microservizio back-end potrebbe avere solo tolleranza di errore e sicurezza. Se i microservizi hanno comunicazioni sincrone tra loro, la dipendenza tra di esse produce spesso la necessità di condividere le stesse caratteristiche di architettura.
La progettazione basata su domini offre un framework che agevola la creazione di microservizi ben progettati. La progettazione basata su domini prevede due fasi distinte, quella strategica e quella tattica. Nella progettazione basata su domini strategica, si definisce la struttura su vasta 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.
In questo articolo e nella prossima procedura verranno illustrati i passaggi seguenti, applicandoli all'applicazione di recapito tramite drone:
Iniziare analizzando 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.
In seguito, verranno definiti i contesti delimitati del dominio. Ogni contesto delimitato contiene un modello di dominio che rappresenta un sottodominio specifico dell'applicazione principale.
All'interno di un contesto delimitato applicare gli schemi di progettazione basata su domini tattica per definire entità, aggregazioni e servizi di dominio.
Usare i risultati del passaggio precedente per identificare i microservizi nell'applicazione.
In questo articolo vengono illustrati i primi tre passaggi, che si occupano principalmente di DDD. Nell'articolo successivo verranno identificati i microservizi. In ogni caso, è importante ricordare che la progettazione basata su dominio è un processo iterativo e continuo. I vincoli del servizio non sono scolpiti nella pietra. Con l'evolvere dell'applicazione, si potrebbe decidere di suddividere un servizio in vari servizi più piccoli.
Nota
Questo articolo non contiene un'analisi dei domini completa ed esaustiva. Abbiamo deliberatamente mantenuto l'esempio breve, per illustrare i punti principali. Per informazioni dettagliate sulla progettazione basata su domini, leggere Domain-Driven Design di Eric Evans, il libro che ha coniato per primo il termine. Un altro riferimento consigliato è Implementing Domain-Driven Design di Vaughn Vernon.
Scenario: Recapito tramite drone
Fabrikam, Inc. sta avviando un servizio di recapito tramite drone. La società gestisce una flotta di droni. Le aziende possono registrarsi per usare il servizio e gli utenti possono richiedere un drone per prelevare merci da consegnare. Quando un cliente pianifica un prelievo, un sistema back-end assegna un drone e invia all'utente una notifica con un tempo di recapito stimato. Durante la consegna, il cliente può tenere traccia della posizione del drone, con un'ora di consegna stimata che viene aggiornata continuamente.
Questo scenario prevede un dominio piuttosto complesso. Alcuni dei problemi aziendali da affrontare includono la pianificazione dei droni, il monitoraggio dei pacchetti, la gestione degli account utente e l'archiviazione e l'analisi dei dati cronologici. Fabrikam vuole inoltre accelerare i tempi di immissione sul mercato e di iterazione, aggiungendo nuove caratteristiche e funzionalità. L'applicazione deve operare a livello cloud, con un obiettivo del livello di servizio elevato. Fabrikam prevede inoltre che le diverse parti del sistema avranno requisiti molto diversi per l'archiviazione dei dati e le query. Tutte queste considerazioni hanno portato Fabrikam a scegliere un'architettura di microservizi per l'applicazione di recapito tramite drone.
Analizzare il dominio
La progettazione basata su dominio consente di progettare microservizi affinché ogni servizio si adatti naturalmente a un requisito aziendale funzionale. Permette di evitare che la progettazione sia determinata dai vincoli organizzativi o dalle scelte tecnologiche.
Prima di passare alla scrittura del codice, è necessaria una panoramica generale del sistema che verrà creato. La progettazione basata su dominio 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 fornisce un linguaggio comune per sviluppatori ed esperti di dominio.
Per iniziare, eseguire un mapping di tutte le funzioni aziendali con le relative connessioni. Si tratta probabilmente di 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.
Esempio: Applicazione di recapito tramite drone
Dopo alcune analisi iniziali, il team di Fabrikam ha creato uno schizzo approssimativo che descrive il dominio di recapito tramite drone.
- La spedizione è posizionata al centro del diagramma, perché è l'attività principale dell'azienda. Tutto gli altri elementi del diagramma esistono per abilitare questa funzionalità.
- Anche la gestione dei droni fa parte del core business. Le funzionalità strettamente correlate alla gestione dei droni includono la riparazione dei droni e l'uso dell'analisi predittiva per prevedere quando sarà necessaria la manutenzione dei droni.
- L'analisi ETA (tempo stimato per il completamento) fornisce la stima delle tempistiche per ritiro e consegna.
- Il trasporto di terze parti consentirà all'applicazione di pianificare metodi di trasporto alternativi se il drone non può effettuare la consegna completa di un pacchetto.
- La condivisione dei droni è una possibile estensione del core business. L'azienda potrebbe avere una capacità in eccesso durante determinati orari e noleggiare quindi i droni che altrimenti rimarrebbero inattivi. Questa funzionalità non sarà inclusa nella versione iniziale.
- La videosorveglianza è un'altra area in cui l'azienda potrebbe espandersi in un secondo momento.
- Gli account utente, la fatturazione e il call center sono sottodomini che supportano il core business.
Si noti che a questo punto del processo non è ancora stata presa alcuna decisione in merito all'implementazione o alle tecnologie. Alcuni sottosistemi potrebbero prevedere l'uso di sistemi software esterni o di servizi di terze parti. Anche in questo caso, l'applicazione deve interagire con tali sistemi e servizi, quindi è importante includerli nel modello di dominio.
Nota
Quando un'applicazione dipende da un sistema esterno, esiste il rischio che l'API o lo schema dei dati del sistema esterno penetri nell'applicazione, compromettendone la progettazione dell'architettura. Questo si verifica in particolare con i sistemi legacy che non seguono le procedure consigliate moderne e che usano API obsolete o schemi dei dati intricati. In questo caso, è importante stabilire un limite ben definito tra i sistemi esterni e l'applicazione. Per questo scopo, è consigliabile usare il modello Strangler Fig o il modello Livello anti-danneggiamento.
Definire i contesti delimitati
Il modello di dominio includerà rappresentazioni di elementi del mondo reale, ad esempio utenti, droni, pacchetti e così via. 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 dovranno rappresentare molte caratteristiche fisiche dei droni, ad esempio la cronologia di manutenzione, il chilometraggio, l'età, il numero di modello, le caratteristiche delle prestazioni e così via. 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 per il ritiro e la consegna.
Se si tentasse di creare un unico modello per entrambi questi sottosistemi, risulterebbe inutilmente complesso e l'evoluzione del modello nel tempo potrebbe essere compromessa perché qualsiasi modifica dovrà soddisfare più team che lavorano su sottosistemi distinti. Per questo motivo, è consigliabile 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.
Ecco dove entra il gioco il concetto di contesti delimitati della progettazione basata su dominio. 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à a seconda del fatto che le varie funzioni condividano o meno un singolo modello di dominio.
I contesti delimitati non sono necessariamente isolati l'uno dall'altro. In questo diagramma, le linee continue che connettono i contesti delimitati rappresentano la posizione di interazione di due contesti delimitati. Ad esempio, la spedizione dipende dagli account utente per ottenere le informazioni relative ai clienti e dalla gestione dei droni per pianificare i droni della flotta.
Nel libro Domain-Drive Design Eric Evans descrive vari schemi per mantenere l'integrità di un modello di dominio quando interagisce con un altro contesto delimitato. Uno dei principi fondamentali dei microservizi è che i servizi comunicano tramite API ben definite. Questo approccio corrisponde a due schemi che Evans chiama Open Host Service (servizio host aperto) e Published Language (linguaggio pubblicato). Nello schema Open Host Service un sottosistema definisce un protocollo formale (API) per consentire la comunicazione con altri sottosistemi. Lo schema Published Language estende questo concetto pubblicando l'API in un formato che altri team possono usare per la scrittura dei client. Nell'articolo Progettazione di API per microservizi viene illustrato l'uso di OpenAPI Specification (in precedenza noto come Swagger) per definire descrizioni di interfaccia indipendenti dal linguaggio per le API REST, espresse in formato JSON o YAML.
Nella parte rimanente di questo articolo verrà illustrato il contesto delimitato per il recapito.
Passaggi successivi
Dopo aver completato un'analisi del dominio, il passaggio successivo consiste nell'applicare il DDD tattico per definire i modelli di dominio con maggiore precisione.