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 tale regola in pratica richiede un pensiero attento. Non esistono processi meccanici in grado di generare la progettazione "corretta". È necessario valutare attentamente il dominio, i requisiti e gli obiettivi aziendali. 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 per la progettazione di microservizi.

Questo articolo usa un servizio di recapito 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.

La progettazione basata su dominio offre un framework che agevola la creazione di microservizi ben progettati. La progettazione basata su dominio prevede due fasi distinte, quella strategica e quella tattica. Nella progettazione basata su dominio 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 con accoppiamento poco rigido e coesione elevata.

In questo articolo e nel prossimo articolo verranno illustrati i passaggi seguenti, applicandoli all'applicazione Recapito drone:

1. Si inizierà dall'analisi del dominio aziendale per acquisire informazioni sui 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. 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.

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. Usare i risultati del passaggio precedente per identificare i microservizi nell'applicazione.

In questo articolo vengono illustrati i primi tre passaggi, che sono principalmente interessati a 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.

Scenario: recapito di droni

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 recapitare. 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 il recapito, il cliente può tenere traccia della posizione del drone, con un tempo stimato di arrivo che viene aggiornato 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. DDD inizia modellazione del dominio aziendale e 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 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.

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 e l'analisi predittiva dei droni dovranno rappresentare molte caratteristiche fisiche dei droni, ad esempio la cronologia della 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.

Qui entra in gioco il concetto DDD di contesti delimitati . 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.

Risorse correlate

• Progettazione dell'architettura dei microservizi
• Progettare un'architettura di microservizi
• Identificare i limiti dei microservizi
• Scegliere un'opzione di calcolo di Azure per i microservizi