La radice aggregata con gerarchia profonda è appropriata in DDD?

Question

Ho un sistema in cui un utente risponde alla domanda in un modulo. Ho oggetti che rappresentano questo modello, ma non sono abbastanza sicuro su come organizzare questi oggetti in termini di DDD.

1. Modulo (ha un proprio elenco di) Sezioni;
2. Sezione -> (ha il proprio elenco di) Gruppi;
3. Gruppo -> (ha una propria lista di) Domande;
4. Domanda -> (può avere una propria lista di sottointerrogazioni) Domande;
5. Domanda -> (ha il proprio elenco di) Risposte;
6. Risposta -> (ha il proprio elenco di) Answer_Details;
7. Answer_Detail -> (potenzialmente ha il proprio elenco di dettagli secondari) Sub_Answer_Details.

Ogni oggetto ha più di 15 proprietà e ciascuna non ha senso senza il relativo genitore. Secondo DDD, credo che l'entità Form dovrebbe essere una radice aggregata e tutti gli altri oggetti dovrebbero essere oggetti valore. Ciò significa che ho bisogno di un repository solo per l'entità Form. In questo caso, FormRepository sarà ingombrato con tutti i tipi di metodi CRUD per oggetti figlio. Il mio ragionamento è corretto in termini di DDD? Va bene che finisco con un aggregato molto ampio? Credo che una tale rappresentazione possa facilmente portare a problemi di prestazioni.

Answer 1

Sì, la gerarchia profonda è valida in DDD.

Va bene che mi ritrovo con un aggregato molto esteso? - se la realtà è così complessa e il tuo modello di dominio è il migliore che riesci a trovare, finirai con una radice aggregata complessa.

Sì, Form deve essere una radice aggregata.

tutti gli altri oggetti devono essere valore oggetti - mal tutti gli altri oggetti devono essere soggetti radice non aggregate (con Id) senza un repository a prenderli. L'oggetto valore non ha un ID e un oggetto di uguaglianza di valori è determinato solo dai suoi valori di attributo, non dall'uguaglianza di Ids (ulteriori informazioni here).

In questo caso FormRepository sarà ingombra di tutti i tipi di metodi CRUD per oggetti figlio - no, un repository dovrebbe contenere solo metodi per quanto riguarda radice aggregata, cioè Get<T> , Save<T> where T : IAggregateRoot, una volta che si ottiene un esempio di una radice di aggregazione, è possibile attraversare tramite attributi e metodi per ottenere ciò che ti serve.Esempio:

var formId = 23; 
var form = _formRepository.Get(formId); 
var firstGroup = form.Sections.First().Group().First(); 

o meglio

var groupIndex = 1; 
var firstGroup = form.GetGroupAt(groupIndex); 

dove

public Group GetGroupAt(int groupIndex) 
{ 
    Sections.First().Group().ElementAt(groupIndex); 
} 

credo che tale rappresentazione può facilmente portare a problemi di prestazioni - se si utilizza CQRS, vuoi essere chiamata un po 'Form metodo di dominio dal gestore di comandi e se si utilizza NHibernate per la persistenza dell'entità, lo farà per impostazione predefinita t utilizzare il caricamento lazy e caricare solo Form dal DB, quindi caricare solo le entità che si toccano realmente, quindi ad esempio Sections.First() caricheranno tutte le sezioni da DB, ma non i gruppi e il resto. Per eseguire una query, devi creare un FormDto (oggetto di trasferimento dati) e altri dtos eventualmente appiattiti per ottenere i dati nel modulo necessario (che potrebbe essere diverso dalla struttura delle entità e l'interfaccia utente potrebbe guidare la struttura dto). Date un'occhiata al mio blog per informazioni per quanto riguarda DDD/CQRS/NHibernate/Repository

Answer 2

Anche se una risposta è stata accettata ho pensato che tanto vale aggiungere il mio 2 centesimi:

gerarchie profonde sono (probabilmente) bene ma ricorda che l'idea alla base di un aggregato è di impedirlo. Tendo a pensare di entità in un aggregato lungo le linee di:

"Fa questa entità ha alcun significato senza AR?"

Poiché non ho alcun contesto w.r.t. il tuo modello userò Order/OrderLine. Un OrderLine ha un significato senza lo Order? Posso fare qualcosa (comportamento) con la riga ordine da solo? La risposta ovvia qui è "no".

Ogni modello dovrà essere trattato in base al contesto. Ma la proprietà non significa necessariamente contenimento.

Questi possono essere più facile da vedere quando si lavora con i contesti limitati separati forniti si ha l'BCs correggere :)

Nel tuo caso un Answer può avere alcun significato senza la sua Question. Ma forse un Question può vivere in un QuestionBank BC e una particolare domanda può essere utilizzata sia nel tuo Examination BC che nel tuo Enrollment BC. Tutti questi sono totalmente inventati in modo che dipendano dal tuo contesto.

Quindi, se è il caso che Question può essere un AR, allora le domande che appartengono al tuo Form AR possono essere semplicemente un oggetto valore o anche un semplice oggetto interrogativo.