Modelli di dominio condivisi di architettura di microservizi

Supponiamo che abbiamo un'applicazione Spring Boot che utilizza l'architettura dei microservizi. Ciascuno dei servizi ha i propri modelli di dominio, ma ogni servizio deve fare riferimento a un oggetto dominio utente. Quale sarebbe l'approccio migliore su come risolvere questo problema? Sarebbe meglio per ogni servizio avere solo un ID utente e quindi, quando necessario, chiedere al servizio utente i dettagli dell'utente, oppure sarebbe meglio avere una libreria di domini condivisa per tutti i microservizi?

Se hai scelto i microservizi per trarre vantaggio dalla scalabilità, dall'accoppiamento lento e dalla facile modifica indipendente di ciascun servizio, dovresti attenervi ad esso nella massima misura possibile.

Architettura generale

Penso che l'approccio migliore sarebbe:

• disporre di un microservizio per la gestione delle informazioni generali dell'utente;
• mantenere le informazioni utente specifiche del microservizio (ad es. profili, autorizzazioni, preferenze) in ciascun microservizio (utilizzando il riferimento dell'ID generale)

Letture addizionali:

• Questo articolo descrive molto bene questo tipo di architettura e logica, con il caso specifico delle autorizzazioni.
• Questo articolo descrive le sfide e le soluzioni per la gestione dell'identità degli utenti, per evitare che tutti i servizi accedano allo stesso repository.
• Questo articolo descrive come usare JWT per passare l'identità dell'utente tra i servizi (osservando che alcune informazioni di base possono essere fornite nel token ID, il che evita di dover interrogare il servizio utente ancora una volta dopo il login, almeno per molto di base informazione).

Condivisione codice

Ora, se sei d'accordo sulla soluzione sopra, abbiamo un microservizio utente (modello di dominio incapsulante per l'utente) e tutti gli altri servizi sono consumatori dello stesso microservizio. La domanda è quindi sapere se si desidera:

• o ciascun microservizio per reinventare il codice del consumatore, seguendo il dogma della forte separazione per consentire cicli di rilascio flessibili e distinti,
• o per condividere il codice del consumatore come parte della libreria, considerando che queste informazioni fondamentali sono un'estensione del modello di infrastruttura "chassis" .

Non prenderò una posizione netta su questo, poiché ci sono guerre di opinione discutibili su questo argomento di condivisione del codice e non penso di essere in grado di assumere una posizione obiettiva. Ecco già alcune letture aggiuntive:

• Questo articolo pensa che non ci sia la soluzione migliore e tutto dipende dai tuoi obiettivi
• Questa posizione dell'articolo afferma che la condivisione del codice è dannosa solo se crea un forte accoppiamento e la condivisione del codice può portare alcune sinergie
• Questo articolo (delle persone che hanno implementato microservizi su larga scala) insiste sulla necessità di avere build separate e sui potenziali problemi di disattivazione del codice precedente. Avere una libreria condivisa da utilizzare con la gestione di versioni solide non impedisce queste buone pratiche.

La mia opinione personale è che NON DOVREBBE CONDIVIDERE il codice tra l'utente-fornitore e l'utente-consumatore, al fine di evitare un accoppiamento stretto. Tuttavia, POTREBBE CONDIVIDERE il codice di consumo utente tra i consumatori se si dispone di una gestione avanzata della versione. Questo approccio avrebbe alcuni vantaggi:

• È possibile creare diversi microservizi che consumano utenti con versioni diverse del codice di consumo utente condiviso (purché le versioni siano compatibili con il provider di utenti indipendente). Stessa flessibilità che reinventa la ruota ma maggiore produttività.
• È possibile modificare il servizio del fornitore utente in modo indipendente senza impatto sui consumatori.
• Se viene rilevato un bug dal lato del consumo, è possibile correggerlo una volta e distribuire tutti i consumatori come migliori (grazie alla gestione delle versioni). Ciò potrebbe persino portare a una qualità del servizio superiore.
• Se per un motivo sei obbligato ad aggiornare l'API del provider utente, puoi distribuire il consumo utente aggiornato in modo più rapido. Se mantieni attivo il servizio di provider vecchio e nuovo durante la transizione, questa possibilità di condivisione potrebbe consentire di smantellare più rapidamente la versione precedente del fornitore-consumatore.

Eviterei una libreria condivisa, se possibile. Chiediti quali proprietà di un utente necessita di ciascun servizio? Spesso esiste un dominio principale in cui vivrà la maggior parte del comportamento che circonda un utente, con i domini di supporto che spesso richiedono solo un ID utente.

Se il tuo servizio necessita di altri dettagli su un utente, dai un'occhiata ad alcuni suggerimenti qui su come gestire tali situazioni