Identificare i limiti del modello di dominio per ogni microservizio

Suggerimento

Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.

Scaricare il PDF

L'obiettivo durante l'identificazione dei limiti e delle dimensioni del modello per ogni microservizio non è quello di raggiungere la separazione più granulare possibile, anche se è consigliabile orientarsi verso microservizi di piccole dimensioni, se possibile. L'obiettivo dovrebbe invece essere quello di raggiungere la separazione più significativa guidata dalla conoscenza del dominio. L'accento non è sulle dimensioni, ma sulle funzionalità aziendali. Inoltre, se è necessaria una chiara coesione per una determinata area dell'applicazione in base a un numero elevato di dipendenze, ciò indica anche la necessità di un singolo microservizio. La coesione è un modo per identificare come suddividere o raggruppare i microservizi. In definitiva, mentre si acquisiscono maggiori informazioni sul dominio, è consigliabile adattare le dimensioni del microservizio in modo iterativo. Trovare le dimensioni corrette non è un processo monotono.

Sam Newman, promotore riconosciuto di microservizi e autore del libro Building Microservices, evidenzia che è consigliabile progettare i microservizi in base al modello BC (Bounded Context) (parte della progettazione basata su dominio), come introdotto in precedenza. A volte, un BC può essere composto da diversi servizi fisici, ma non viceversa.

Un modello di dominio con entità di dominio specifiche si applica all'interno di un microservizio BC o di un microservizio concreto. Un bc delimita l'applicabilità di un modello di dominio e offre ai membri del team di sviluppo una comprensione chiara e condivisa di ciò che deve essere coeso e cosa può essere sviluppato in modo indipendente. Questi sono gli stessi obiettivi per i microservizi.

Un altro strumento che informa la scelta di progettazione è la legge di Conway, che indica che un'applicazione rifletterà i confini sociali dell'organizzazione che lo ha prodotto. Ma a volte il contrario è vero -the l'organizzazione aziendale è modellata dal software. Potrebbe essere necessario invertire la legge di Conway e costruire i confini nel modo in cui si vuole organizzare l'azienda, appoggiandosi alla consulenza dei processi aziendali.

Per identificare i contesti delimitati, è possibile usare un modello DDD denominato modello di mapping del contesto. Con mapping del contesto, è possibile identificare i vari contesti nell'applicazione e i relativi limiti. È comune avere un contesto e un limite diversi per ogni piccolo sottosistema, ad esempio. La mappa del contesto è un modo per definire e rendere espliciti tali limiti tra domini. Un bc è autonomo e include i dettagli di un singolo dominio -details come le entità di dominio e definisce i contratti di integrazione con altri BCS. È simile alla definizione di un microservizio: è autonoma, implementa determinate funzionalità di dominio e deve fornire interfacce. Ecco perché il mapping del contesto e il modello contesto delimitato sono approcci validi per identificare i limiti del modello di dominio dei microservizi.

Quando si progetta un'applicazione di grandi dimensioni, si noterà come il modello di dominio può essere frammentato. Un esperto di dominio del dominio del catalogo denomina le entità in modo diverso nei domini di catalogo e di inventario rispetto a un esperto del dominio di spedizione, ad esempio. In alternativa, l'entità di dominio utente potrebbe essere diversa in termini di dimensioni e numero di attributi quando si tratta di un esperto CRM che vuole archiviare ogni dettaglio sul cliente rispetto a un esperto del dominio di ordinazione che necessita solo di dati parziali sul cliente. È molto difficile disambiguare tutti i termini di dominio in tutti i domini correlati a un'applicazione di grandi dimensioni. Ma la cosa più importante è che non dovresti provare a unificare i termini. Accettare invece le differenze e la ricchezza fornite da ogni dominio. Se si tenta di avere un database unificato per l'intera applicazione, i tentativi di un vocabolario unificato saranno imbarazzanti e non saranno corretti per nessuno dei più esperti di dominio. Di conseguenza, i BCS (implementati come microservizi) consentono di chiarire dove è possibile usare determinati termini di dominio e dove sarà necessario suddividere il sistema e creare controller di dominio aggiuntivi con domini diversi.

Si saprà che si hanno i limiti e le dimensioni corretti di ogni modello bc e di dominio se si hanno poche relazioni complesse tra i modelli di dominio e in genere non è necessario unire informazioni da più modelli di dominio quando si eseguono operazioni tipiche dell'applicazione.

Forse la risposta migliore alla domanda sulla grandezza di un modello di dominio per ogni microservizio è la seguente: deve avere un bc autonomo, il più isolato possibile, che consente di lavorare senza dover passare costantemente ad altri contesti (altri modelli di microservizi). Nella figura 4-10 è possibile vedere in che modo più microservizi (più BC) hanno un proprio modello e il modo in cui è possibile definire le entità, a seconda dei requisiti specifici per ognuno dei domini identificati nell'applicazione.

Figura 4-10. Identificazione delle entità e dei limiti del modello di microservizio

La figura 4-10 illustra uno scenario di esempio correlato a un sistema di gestione delle conferenze online. La stessa entità viene visualizzata come "Users", "Buyers", "Payers" e "Customers" in base al contesto delimitato. Hai identificato diversi BC che potrebbero essere implementati come microservizi, basandoti sui domini definiti per te dagli esperti di dominio. Come si può notare, esistono entità presenti solo in un singolo modello di microservizio, ad esempio Pagamenti nel microservizio Pagamento. Questi saranno facili da implementare.

Tuttavia, è anche possibile avere entità con una forma diversa, ma condividere la stessa identità tra più modelli di dominio da più microservizi. Ad esempio, l'entità User viene identificata nel microservizio Conferences Management. Lo stesso utente, con la stessa identità, è quello denominato Buyers nel microservizio Ordering o quello denominato Payer nel microservizio Payment e anche quello denominato Customer nel microservizio Customer Service. Ciò è dovuto al fatto che, a seconda del linguaggio comune usato da ogni esperto di dominio, un utente potrebbe avere una prospettiva diversa anche con attributi diversi. L'entità utente nel modello di microservizio denominata Conferences Management potrebbe avere la maggior parte dei relativi attributi di dati personali. Tuttavia, lo stesso utente nella forma di Payer nel microservizio Pagamento o nella forma di Cliente nel servizio clienti di microservizio potrebbe non avere bisogno dello stesso elenco di attributi.

Un approccio simile è illustrato nella figura 4-11.

Figura 4-11. Scomporre i modelli di dati tradizionali in più modelli di dominio

Quando si scompone un modello di dati tradizionale tra contesti delimitati, è possibile avere entità diverse che condividono la stessa identità (anche un acquirente è un utente) con attributi diversi in ogni contesto delimitato. È possibile vedere come l'utente è presente nel modello di microservizio Conferences Management come entità User ed è presente anche sotto forma di entità Buyer nel microservizio Pricing, con attributi alternativi o dettagli sull'utente quando è effettivamente un acquirente. Ogni microservizio o BC potrebbe non avere bisogno di tutti i dati correlati a un'entità User, solo in parte, a seconda del problema da risolvere o dal contesto. Ad esempio, nel modello di microservizio Prezzi non è necessario l'indirizzo o il nome dell'utente, solo l'ID (come identità) e lo stato, che avrà un impatto sugli sconti sul prezzo dei posti per acquirente.

L'entità Seat ha lo stesso nome ma attributi diversi in ogni modello di dominio. Tuttavia, Seat condivide l'identità in base allo stesso ID, come avviene con User e Buyer.

Fondamentalmente, esiste un concetto condiviso di un utente presente in più servizi (domini), che condividono l'identità di tale utente. Tuttavia, in ogni modello di dominio potrebbero essere presenti dettagli aggiuntivi o diversi sull'entità utente. È pertanto necessario eseguire il mapping di un'entità utente da un dominio (microservizio) a un altro.

Esistono diversi vantaggi per non condividere la stessa entità utente con lo stesso numero di attributi tra domini. Un vantaggio consiste nel ridurre la duplicazione, in modo che i modelli di microservizi non dispongano di dati non necessari. Un altro vantaggio è la presenza di un microservizio primario proprietario di un determinato tipo di dati per entità, in modo che gli aggiornamenti e le query per quel tipo di dati siano guidati solo da tale microservizio.

PrecedenteAvanti