Accesso a entità che non sono una radice aggregata

Question

Sto guardando DDD e ho dei pensieri. Su un sito di shopping ho l'ordine tipico.

public class Order
{
    public ICollection<OrderRow> OrderRows { get; set; }
    public ICollection<Payment> Payments { get; set; }
    ...
}

I pagamenti sembrano essere naturali da mettere sull'ordine. Quando si effettua un ordine o si lavora con l'ordine, i pagamenti fanno parte dell'ordine.

Ma in seguito un amministratore vuole gestire i pagamenti separatamente. Ad esempio nell'interfaccia amministrativa ha un elenco di pagamenti che devono essere gestiti.

Come dovrei farlo? I pagamenti dovrebbero essere rimossi dall'ordine ed essere il suo aggregato radice?

Answer 1

La mia comprensione è che gli aggregati possono e si sovrappongono, permettendoti di definire l'aggregato che ha più senso per il contesto aziendale dell'attuale operazione.

Quindi, in questo caso, sì, quando si lavora in termini di ordine, esporresti i pagamenti come parte dell'aggregato dell'ordine, ma ciò non impedisce anche di avere una repository di pagamento dedicata che espone il pagamento come radice aggregata.

Answer 2

Penso che l'entità di pagamento non appartenga all'aggregato dell'ordine. Mentre hai scritto hai funzionalità che funzionano con i pagamenti separatamente. Significa che i pagamenti non vengono utilizzati solo nel contesto dell'ordine. Significa che i pagamenti non appartengono all'ordine aggregato :).
Tuttavia, è possibile disporre di proprietà di pagamenti in classe, anche se non fa parte dell'aggregato degli ordini.

Answer 3

Se un pagamento non può esistere senza un ordine, il pagamento non è una radice aggregata.

Se non si tratta di una radice aggregata, il caricamento degli oggetti dell'ordine appropriati da un ordine e operando su entità di pagamento all'interno sembra avere la maggior parte dell'integrità DDD.