Come posso trasferire in cascata le modifiche da una radice aggregata a un'altra?

Question

Come posso trasferire in cascata le modifiche da una radice aggregata a un'altra?

#1 da (1 voti)

1

Ho problemi a modellare una relazione in DDD. Ho quattro entità:

Reclamo: definisce l'accesso a un servizio.
Servizio: un servizio Web. Un servizio ha molte rivendicazioni e può appartenere a qualsiasi numero di squadre.
Ruolo: contiene una raccolta di reclami da qualsiasi numero di servizi. I ruoli appartengono sempre a un team.
Squadra - contiene una raccolta di ruoli e servizi.

Quando rimuovo un reclamo da un servizio, deve essere rimosso anche da tutti i ruoli a cui è stato assegnato tale reclamo. Allo stesso modo, quando cambio il nome di un servizio, quel nome dovrebbe riflettersi in tutti i team.

Attualmente dispongo di una radice aggregata del servizio (per consentire l'aggiunta e la modifica dei servizi indipendentemente da un singolo team) e una radice aggregata del team (per consentire la gestione dei ruoli specifici del team). Questo crea due problemi:

Le modifiche nell'aggregazione del servizio non si riflettono nell'aggregazione del team
Quando un reclamo viene rimosso da un servizio, non c'è modo di sovrapporlo nei ruoli del team.

C'è qualcosa di chiaramente orribilmente sbagliato nella mia modella, e mi chiedevo se qualcuno potesse illuminare dove sono andato storto.

domain-driven-design

posta pixelbadger 14.04.2016 - 16:36

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Supporto unicode multipiattaforma per lo strumento da riga di comando Python Il modo più efficace per mantenere il conteggio degli oggetti nello stato X senza contare costantemente

score 1 · Answer 1

Perché un ruolo ha una relazione diretta con il servizio, quando la relazione richiede ovviamente un reclamo per esistere? Dimentica quello.

Rispettivamente dove c'è una relazione tra servizio e squadra? Aggiungi un riferimento indiretto tramite un'entità Proprietà per modellarlo.

Scegliere Team e Servizio come unici aggregati di root è corretto.

Team    1 <-> * Role
Role    1 <-> * Claim

Service 1 <-> * Claim

Team    1 <-> * Ownership
Service 1 <-> * Ownership

Rendendo le relazioni traversabili in entrambe le direzioni, puoi già raggiungere ogni entità necessaria per accedere a tutte le informazioni correlate richieste.

Non è necessario archiviare mai i nomi dei servizi in una squadra, tali informazioni possono essere aggregate navigando sia lungo il Claim che nelle relazioni di proprietà.

Poiché un reclamo contiene sia un riferimento su un ruolo che un servizio, è necessario attraversare entrambi i genitori quando si elimina un reclamo. Lo stesso vale per la proprietà. Non importa quale genitore possiede il bambino e che contiene solo un riferimento, questo è solo un dettaglio di implementazione.