Modello di dominio condiviso tra diversi microservizi

In un'architettura di Microservices, ognuno è assolutamente indipendente dagli altri e deve nascondere i dettagli dell'implementazione interna.

Se condividi il modello, abbini i microservizi e perdi uno dei maggiori vantaggi in cui ogni team può sviluppare il microservizio senza restrizioni e la necessità di sapere come evolvere altri microservizi. Ricorda che puoi persino usare lingue diverse in ognuna di esse, questo sarebbe difficile se inizi a unire i microservizi.

Se sono troppo correlati forse sono davvero uno come dice @soru.

Domande correlate:

• Perché è così brutto leggere i dati da un database" di proprietà "di un altro microservizio
• Come fai gestire i concetti condivisi in un'architettura di microservizi?

Se due servizi sono sufficientemente interconnessi che sarebbe difficile implementarli senza condividere DTO e altri oggetti del modello, è un segnale strong che non dovresti avere due servizi.

Certamente l'esempio ha poco senso come due servizi; è difficile immaginare una specifica per "Gestione utenti" così complicata da mantenere un'intera squadra così impegnata da non avere il tempo di fare l'autenticazione.

Se per qualche motivo lo fossero, quindi comunicherebbero utilizzando stringhe fondamentalmente arbitrarie, come in OAuth 2.0 .

Puoi considerarli come due contesti separati separati (nel linguaggio del design basato sul dominio). Non dovrebbero condividere alcun dato tra di loro, a parte un ID usato per correlare l'Utente "del contesto di autenticazione con" Utente "dell'altro contesto. Possono avere ciascuno la propria rappresentazione di cosa sia un "utente" e il proprio modello di dominio, che contiene solo le informazioni necessarie per svolgere la propria responsabilità commerciale.

Ricorda che un modello di dominio non tenta di modellare una "cosa" del mondo reale, ma quale cosa è in un particolare contesto (come Identità / Gestione delle autorizzazioni, Risorse umane, ecc.)

They both have a concept of a User, and will talk about Users through calls to each other.

Sono anche d'accordo con ciò che @soru ha detto. Se un servizio ha bisogno di dati di un altro servizio, i loro limiti sono errati.

Una bella soluzione è ciò che @pnschofield ha ideato: tratta i tuoi servizi come contesti limitati.

Parlando dell'argomento, mettilo tra poco: i modelli di dominio condiviso uccidono l'autonomia del servizio, trasformando il tuo sistema di microservizi in un monolite distribuito. Che è apparentemente anche peggiore di un monolite.

Quindi c'è ancora una questione generale non risolta - come definire i confini del servizio o del contesto, in modo che prosperino in alta coesione e in una buona qualità di accoppiamento.

Ho trovato una soluzione per trattare i miei contesti come una capacità aziendale. È una responsabilità aziendale di livello superiore, la funzionalità aziendale, che contribuisce all'obiettivo generale dell'azienda. Puoi pensare a loro come a passi che la tua organizzazione deve percorrere per ottenere valore per il business.

La mia tipica sequenza di passaggi che passo quando identifico i limiti del servizio è la seguente:

1. Identifica le capacità aziendali di livello superiore. Di solito sono simili tra le organizzazioni dello stesso dominio. Puoi avere un'idea di come appare selezionando modello della catena del valore di Porter .
2. All'interno di ciascuna funzionalità, approfondisci e identifica le funzionalità secondarie.
3. Nota la comunicazione tra le funzionalità. Guarda cosa fa un'organizzazione. Di solito, la comunicazione è concentrata all'interno delle capacità, notificando il resto sul risultato del suo lavoro. Pertanto, quando si implementa l'architettura tecnica, il servizio deve comunicare anche tramite eventi. Questo ha molteplici conseguenze positive. Con questo approccio i tuoi servizi sono autonomi e coesi. Non hanno bisogno di comunicazione sincrona e transazioni distribuite.

Probabilmente un esempio di questa tecnica sarebbe di un certo interesse per voi. Non esitate a farmi sapere cosa ne pensate, dal momento che ho trovato questo approccio davvero redditizio. Certo che può funzionare anche per te.