Associazioni many-to-many in microservices

Prima di tutto, inizierei con la descrizione del dominio. Non hai menzionato di cosa si tratta (posso immaginarlo, ma sarebbe solo una supposizione). Successivamente, proverei a scomporlo usando analisi della catena del valore o mappatura della capacità aziendale . E solo dopo penserei all'attuazione.

Considerando il tuo problema, la prima cosa che mi viene in mente è che hai identificato i limiti del servizio errati, semplicemente perché hanno bisogno dei reciproci dati. Non vuoi finire con monolito distribuito , vero?

La seconda cosa è che probabilmente non hai elaborato il tuo dominio abbastanza bene. Quale concetto è rappresentato con users table? È un registered user , con tutte le informazioni e il comportamento richiesti per la registrazione? Sei sicuro che sia il concetto giusto per comunicare con trackers (qualunque esso sia)? Quindi, se ho capito bene, la tua opzione 2 è esattamente quella: introducendo il concetto di owner che è molto più vicino al tuo dominio. Se è davvero così, sono per l'opzione 2.

However, it seems out of scope for microservice B. Why should microservice B care that microservice A wants to create an association?

Riguarda i confini. Immagino tu voglia formare microservizi attorno alle entità. Ecco dove SOA non è riuscito con il suo architettura di servizio desiderata . L'approccio migliore è creare servizi che rappresentino alcune funzioni aziendali, in modo da incapsulare sia i dati che il comportamento. Dal punto di vista più pratico, si tratta di creare servizi intorno a processi aziendali o casi d'uso. Ad esempio, potresti avere un servizio per la registrazione dell'utente. Contiene i dati e il comportamento dell'utente necessari per registrare un utente. Quindi il concetto di user è formato naturalmente, e appartiene solo al servizio A. E questo mi porta al punto successivo: l'altro modo di pensare ai servizi è contesto inbound . È buona norma allineare servizi e contesti limitati.

Quando l'utente è registrato, potrebbe essere emesso l'evento UserCreated . Il tuo secondo servizio credo sia interessato a questo. Quindi, una volta ricevuto, un'entità completamente diversa potrebbe essere creata, ad esempio, Owner entità (qualunque cosa sia, sia). Sono abbastanza sicuro che ci siano molte collaborazioni interessanti tra questo e l'entità tracker : tienili in un unico servizio.

Sii estremamente prudente con l'opzione 3. Se copi i dati, segue la funzionalità. Risulta in accoppiamento stretto. E non coprire con il termine CQRS , non si tratta di sincronizzazione dei dati tra servizi tramite eventi.

Molto dipende dal dominio stesso. Se un utente con zero tracker non ha senso, il servizio utente deve conoscere i tracker. Se un tracker deve avere un utente, i tracker devono conoscere gli utenti. Se qualcosa come avere un tracker con più proprietari o essere in grado di trasferire un tracker da un utente a un altro ha senso, allora forse questa informazione appartiene a un altro servizio.

Domanda: perché i tuoi dati sono separati da Datatables?

Tenderei ad andare con l'opzione 3: i servizi sono completamente separati e possono rispondere alle domande a cui potrebbero aver bisogno di rispondere. Inoltre, sono molto più resilienti. Ma fai attenzione, i tuoi servizi potrebbero non sincronizzarsi se perdono gli eventi, ma ciò può essere risolto con coerenza finale.

Inoltre, potresti prendere in considerazione l'unione di entrambi i servizi - se entrambi non sono in grado di rispondere senza conoscersi l'un l'altro, li unirò semplicemente perché probabilmente fanno parte di un singolo dominio.

La risposta di Zapadlo contiene molte buone informazioni e ragionamenti. Aggiungerò qui alcuni consigli pratici che potrebbero rendere più semplice la risoluzione dei problemi e il consiglio in quella risposta.

Il modo in cui hai inquadrato la tua domanda di progettazione riguarda le strutture del database e come adattare un nuovo requisito per le tue strutture. Ciò implica che stai creando il progetto del servizio dal tuo modello di dati. Ad esempio, quello che non vedo è come si debba accedere o utilizzare la relazione tra utenti e tracker.

Nella progettazione del servizio, la struttura dell'interfaccia è la cosa più importante del design. In effetti, l'implementazione è quasi irrilevante in confronto, in particolare nel caso dei microservizi. Il motivo è che una volta messo in atto il servizio, tutte le dipendenze del servizio dovrebbero esistere solo nell'interfaccia. Se hai ragione, dovresti essere in grado di riscrivere completamente l'implementazione senza alcun consumatore. E questo è il principale vantaggio dell'autonomia. A nessuno importa come l'hai costruito. Hanno solo bisogno che funzioni come hai comunicato.

Prima che chiunque possa determinare come appare nel database o dove vuoi, devi davvero spiegare come queste informazioni verranno utilizzate. È qualcosa che verrà esposto attraverso un servizio o è una sorta di dati che vuoi rimescolare per l'analisi?

Da una nota a margine, eviterei le dipendenze bidirezionali a quasi tutti i costi. Se hai delle dipendenze, vuoi davvero che una sola parte conosca l'altra. Una volta che le dipendenze sono in entrambe le direzioni, i servizi diventano essenzialmente un'unità atomica.