DDD: è corretto per un aggregato radice contenere un riferimento a un altro aggregato radice?

Quando si segue la progettazione guidata dal dominio (DDD), è corretto che un aggregato radice contenga un riferimento a un'entità interna che risulta essere l'entità radice su un aggregato separato?

Credo che questo non sia corretto, principalmente a causa di questa regola sul libro blu :

Nulla al di fuori dei confini di AGGREGATE può contenere un riferimento a qualsiasi cosa all'interno, tranne che alla radice ENTITY. La radice ENTITY può trasferire i riferimenti alle ENTITÀ interne ad altri oggetti, ma tali oggetti possono usarli solo in modo transitorio e non possono aggrapparsi al riferimento. Il root può consegnare una copia di un VALUE OBJECT a un altro oggetto e non importa cosa gli succede, perché è solo un VALORE e non avrà più alcuna associazione con AGGREGATE.

Se un aggregato di root contiene un riferimento a un altro aggregato di root, il limite del primo viene violato e l'intero concetto di aggregato è corrotto, quindi credo che se un aggregato di root sembra avere bisogno di contenere un riferimento a un altro aggregato di root, allora ho bisogno per creare un'entità diversa , che probabilmente condividerà alcuni degli stessi membri dell'altra entità radice, ma non avrà un'identità globale, come afferma questa altra regola nel libro:

Le ENTITÀ di root hanno un'identità globale. ENTITÀ all'interno del confine hanno identità locale, unica solo all'interno dell'AGGREGATO.

Credo che questo sarebbe il modo corretto di procedere, ma dal momento che sembra ripetitivo e ridondante (quando rimosso dal contesto di DDD, con OOP puro), sto chiedendo un feedback.

object-oriented domain-driven-design

— Lesair Valmont
fonte

Cosa intendi con "entità interna (che sembra essere l'entità radice su un aggregato separato)"?

— Erik Eidt,

FWIW, Qualsiasi cosa può riferirsi a un'entità radice aggregata poiché queste sono le cose che hanno identità globale; se il referrer sia esso stesso un'entità radice o no è irrilevante.

— Erik Eidt,

Come ha detto Erik. Inoltre, non importa se lo fai riferimento usando ID o riferimento nel tuo modello. Entrambi si convertiranno in ID a livello di DB e la presenza di un riferimento consente a ORM di caricare lentamente l'entità su richiesta.

— Euforico

Risposte:

Potresti interpretare in modo eccessivo il libro. In pratica dice: qualsiasi cosa al di fuori di un aggregato non può contenere un riferimento a qualcosa al suo interno tranne la radice. Pertanto, detenere un riferimento a una radice è legittimo. Tenere un riferimento a una radice non significa che faccia parte del tuo aggregato e che puoi controllarne gli invarianti. Mantiene le proprie invarianti e autonomia.

Tuttavia,

Una buona pratica comunemente accettata è fare riferimento a un AR memorizzando il suo ID, non un riferimento completo.
Approcci più moderni alla progettazione aggregata (vedi il Libro rosso ) sostengono una separazione più pulita tra aggregati. Una transazione commerciale dovrebbe cambiare solo lo stato di un singolo aggregato. In base a questo presupposto, la necessità di memorizzare un riferimento a un altro aggregato tende a scomparire perché non si modificheranno 2 aggregati contemporaneamente.

è corretto che un aggregato radice contenga un riferimento a un'entità interna che risulta essere l'entità radice su un aggregato separato?

Questo non succede mai. Un oggetto valore può far parte di più aggregati, ma non un'entità. Il motivo è che nulla ti impedirebbe di condividere la stessa istanza di entità tra aggregati. Diciamo che l'istanza dell'entità E appartiene a entrambe le istanze aggregate A e B. Poiché la premessa di DDD è che l'aggregato è il punto di ingresso, si sarebbe in grado di caricare A, modificare l'entità E attraverso di essa, violando silenziosamente gli invarianti da B (che non hai caricato).

Vedi la risposta di Greg Young qui: http://domain-driven-design.3010926.n2.nabble.com/Can-an-Entity-be-Shared-across-many-Aggregates-td7579277.html

— guillaume31
fonte

Grazie Guillaume per la risposta chiara, concisa e perspicace. Il vero savoir-faire degli intenditori del DDD. Questo è quello che stavo cercando. Chapeau!

— Lesair Valmont,

So che potrebbe essere una domanda sciocca, ma potrei chiedere qual è il significato holding a referencein questo contesto? perché ho confuso quando lo hai detto: holding a reference to a root is legitpoi hai detto:

This never happens. A Value Object can be part of multiple Aggregates, but not an Entity. The reason is, nothing would then prevent you from sharing the same entity instance between Aggregates.

— Anyname Donotcare

Mantieni un riferimento = mantienilo internamente / durevolmente, come membro della classe. La dicotomia qui è radice vs non radice. È possibile mantenere un riferimento radice ma non un riferimento non radice.

— guillaume31,

@ guillaume31 grazie mille, ma potrei chiederti se va bene mantenere idun'entità interna (non root) in un altro aggregato o questo viola se (root o no)?

— Anyname Donotcare,

Cosa faresti con quell'ID? Anche i repository ti danno solo radici, non entità interne.

— guillaume31,

Il tuo oggetto radice aggregato dovrebbe (generalmente) avere solo proprietà che fanno parte del suo dominio.

Se si dispone di un oggetto AR con una proprietà che non è nell'aggregato, ci si trova immediatamente di fronte alla domanda. 'Perchè no?'

Potresti aggiungere l'ID dell'altro oggetto forse? O iniettare un repository?

Ma sembra che dovresti aggiungere un servizio interdominio che fa riferimento a entrambi gli oggetti root ed esegue la logica richiesta

— Ewan
fonte

Ewan, stavo pensando di riutilizzare una classe tra due diverse aggregazioni nel senso di OOP, piuttosto che avere un servizio di dominio che funge da script aziendale che farà un po 'di lavoro con i due diversi aggregati DDD. In conclusione, concordo con te, la mia radice aggregata dovrebbe avere solo proprietà che fanno parte del suo dominio.

— Lesair Valmont,