DDD:aggregate root domanda

Question

Diciamo che ho avuto 2 soggetti - Foo e Bar.Pippo è un aggregato di root e contiene Bar.Da quanto ho capito, dovrebbe assomigliare a questo:

public class Foo{
    private readonly Bar Bar;
}

Voglio fornire funzionalità per gli utenti di scegliere Barre per Foos da un elenco definito (e cambiare).

Se i repository sono supposti per essere aggregato radici solo significa che non ci sarà nessun repository per Bar entità.

Questo porta al problema - Bar non può essere creato/aggiornato in modo indipendente, senza un riferimento a Pippo.

Vuol dire che la Barra si suppone di avere un repository nonostante che esso non ha alcun significato senza un Pippo?

Answer 1

Se si desidera selezionare da un elenco di Bar dove non sono associati con Pippo, allora questo non è un aggregato di root.Per esempio, non è possibile ottenere la lista dei OrderItems senza il loro Ordine, quindi questo è il singolo aggregato di root (Ordine), ma è possibile ottenere un elenco di Prodotti da assegnare al OrderItems, in modo che il Prodotto non è parte dell'Ordine aggregate root.

Si noti che, mentre OrderItem è parte di un Ordine di aggregazione di root, è possibile creare e aggiornare in modo indipendente.Ma, non si può ottenere senza riferimento all'Ordine.Stesso per il tuo Bar, anche se era parte di Pippo, si potrebbe ottenere ogni(Pippo.Bar) e lavorare con esso, o Pippo.AddBar(Bar nuovo()).Ma se avete bisogno di ottenere Elenco senza Pippo, pluto non è parte di Pippo di aggregazione.Si tratta di una entità separata.

Beh, per come la vedo io DDD qui, ma io non sono Eric Evans, naturalmente.

Answer 2

Le ragioni per avere radici di aggregazione sono:

1. Forniscono controllata e diretta accesso alle entità composite
2. Si può far rispettare le regole per garantire che l'intero aggregato è valida

La mia opinione: Se è necessario selezionare gli oggetti Bar senza Foo, utilizzare un BarRepository.

Ma ... Che cosa succede se si aggiorna un Bar, e si rompe una regola di convalida per la sua Foo genitore? Se questo potrebbe accadere, si dovrebbe accedere Bar via è Foo genitore.

Se, tuttavia, è necessario accedere a un gruppo di oggetti Bar (ad esempio per un processo batch o un report), e sa che Foos non sarà possibile ottenere rotto, andare avanti e l'accesso via BarRepository.

Ricordate che radici di aggregazione possono essere composte da altre radici di aggregazione. Si può scoprire che Bar è una radice di aggregazione per sé, dando giustificazione per un BarRepository:)

Answer 3

Sei sicuro di Bar bisogno di essere un entità? Avete la necessità di tenere traccia e cambiarlo nel dominio? Se si può guardare come un oggetto di valore, vorrei suggerire che viene scaricata da un servizio e poi "collegare" l'oggetto valore selezionato per l'entità Foo. Per istanti attraverso un elenco a discesa.