Modello di dominio condiviso tra diversi microservizi

Immagina uno scenario di due diversi microservizi. Uno per gestire l'autenticazione all'interno del servizio, l'altro si occupa della gestione degli utenti. Entrambi hanno un concetto di Utente e parleranno degli Utenti tramite chiamate reciproche.

Ma dove dovrebbe appartenere il modello di dominio di un "utente"? Avrebbero entrambi una diversa rappresentazione di ciò che un utente è a livello di database? Che dire di quando avremo un UserDTO da utilizzare nelle chiamate API, ne avrebbero uno per le loro rispettive API?

Qual è la soluzione generalmente accettata per questo tipo di problema architettonico?

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

Se condividi il modello stai accoppiando i microservizi e perdi uno dei maggiori vantaggi in cui ogni team può sviluppare il suo microservizio senza restrizioni e la necessità di sapere come evolvono gli altri microservizi. Ricorda che puoi anche usare lingue diverse in ognuna, questo sarebbe difficile se inizi a accoppiare i microservizi.

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

Domande correlate:

• Perché è così male leggere i dati da un database "di proprietà" di un microservizio diverso
• Come gestite i concetti condivisi in un'architettura di microservizi?

Se due servizi sono sufficientemente intrecciati da rendere difficile implementarli senza condividere DTO e altri oggetti modello, questo è un segnale forte che non si dovrebbero avere due servizi.

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

Se per qualche motivo lo fossero, allora comunicherebbero usando quelle che sono stringhe sostanzialmente arbitrarie, come in OAuth 2.0 .

Puoi pensarli come due contesti rilegati separati (nel linguaggio Design guidato dal dominio). Non dovrebbero condividere alcun dato tra loro, a parte un ID utilizzato per correlare "Utente" del contesto di autenticazione con "Utente" dell'altro contesto. Ognuno di essi può avere la propria rappresentazione di cosa sia un "Utente" e il proprio modello di dominio, che sono solo le informazioni necessarie per svolgere la propria responsabilità aziendale.

Ricorda che un modello di dominio non cerca di modellare una "cosa" del mondo reale, ma quale sia quella cosa in un particolare contesto (come Identity / Authorization Management, o Human Resources, ecc.).

Entrambi hanno un concetto di Utente e parleranno degli Utenti tramite chiamate reciproche.

Concordo anche con ciò che ha detto @soru. Se un servizio necessita dei dati di un altro servizio, i loro limiti sono errati.

@Pnschofield ha creato una buona soluzione: trattare i tuoi servizi come un contesto limitato.

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

Quindi c'è ancora una questione generale irrisolta: come definire i confini del servizio o del contesto, in modo che prosperino in alta coesione e scioltezza bontà di accoppiamento.

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

La mia sequenza tipica di passi che faccio quando identifico i confini del servizio è la seguente:

1. Identificare le capacità aziendali di livello superiore. Di solito sono simili tra le organizzazioni dello stesso dominio. È possibile avere un'idea di come si presenta il modello di catena del valore di Porter .
2. All'interno di ogni capacità, approfondisci e identifica le sotto-capacità.
3. Nota la comunicazione tra le funzionalità. Guarda cosa fa un'organizzazione. Di solito, la comunicazione è concentrata all'interno delle capacità, notificando al resto il risultato del suo lavoro. Pertanto, quando si implementa l'architettura tecnica, anche il servizio deve comunicare tramite eventi. Ciò ha molteplici conseguenze positive. Con questo approccio i tuoi servizi sono autonomi e coerenti. Non hanno bisogno di comunicazioni sincrone e transazioni distribuite.

Probabilmente un esempio di questa tecnica potrebbe interessarti. Non esitate a farmi sapere cosa ne pensate, poiché ho trovato questo approccio davvero proficuo. Sicuro che può funzionare anche per te.

Microservice non si tratta di "condividere nulla", ma di "condividere il meno possibile". Nella maggior parte dei casi "Utente" è un'entità davvero comune (solo perché l'utente è identificato da un identificatore condiviso - userId / email / telefono). Tale tipo di entità condivise per definizione. Il modello utente non rientra nell'ambito di un microservizio. Quindi è necessario disporre di uno schema globale, in cui l'utente (solo i loro campi più comuni) dovrebbe essere posizionato. In casi rigorosi è solo id.