Se un'entità diventa la radice di un aggregato, la radice aggregata utilizza l'ID esistente dell'entità radice o l'AR crea il proprio ID?

Question

In Design guidato dominio (DDD), un'entità ha sempre la propria identità univoca.

Nella mia lettura su DDD ho visto affermazioni ed esempi che sembrano mescolare i concetti di "identità univoca" tra entità e radici aggregate. A seconda dell'esempio, possono implicare che:

.
• Ho solo bisogno di una delle interfacce qui sotto.

o

.
• ho bisogno di entrambi.

Mi piacerebbe sapere quale approccio è "corretto" per quanto riguarda "Eric Evans Type DDD" è preoccupato.

Ad esempio, diciamo che le tue entità implementino questa interfaccia e restituiamo un GUID quando questo metodo è chiamato:

public interface IEntity
{
   object IdThatIsUniqueForThisEntityObject { get; }
}

.

hai anche bisogno di quello qui sotto o no?

public interface IAggregateRoot
{
   object IdThatIsUniqueForThisAggregateRootObject { get; }
}

.

La radice aggregata è necessaria per implementare un'interfaccia come quella sopra in modo che possa rappresentare il suo ID .

o se la radice aggregata usa semplicemente l'entità della radice (idthatisuniqueforthisentyobject) per rappresentare l'ID univoco della radice aggregata?

Answer 1

Hai solo bisogno dell'entità.Non esiste un'identità radice aggregata aggiuntiva creata.Una radice aggregata è un aggregato che viene utilizzato per controllare l'accesso e organizzare oggetti come un'unica unità di lavoro del database.L'aggregato non conferisce alcun tipo di "nuovo" o identità aggiuntiva per un oggetto.

Un'entità ha sempre è un'identità di entità unica e che dovrebbe essere sufficiente.Per definizione, un'operazione che recupera un'entità che è una radice aggregata che recupera anche l'aggregato nel farlo.Non c'è alcun concetto di un'entità che a volte è solo l'entità standalone e altre volte la radice aggregata.Quindi non c'è anche bisogno di un concetto di "identità radicata aggregata".