Sto progettando un'applicazione web che utilizza Domain-Driven Design. Ho lo scenario seguente:
Ogni Application Group può avere un Application e ogni Application può avere più Configurations . Sto cercando di capire quale sarà l'oggetto aggregato ...
Quali saranno le radici aggregate e perché?
Credo che Eric Evans abbia scritto: "I modelli non hanno né ragione né torto, sono semplicemente più o meno utili". La domanda è, quale modello ti aiuta a risolvere il problema in modo pulito. Semplicemente facendo riferimento ai nomi di un certo numero di classi, è impossibile per gli altri determinare quale modello potrebbe aiutarti a risolvere il tuo problema.
Ma per quanto riguarda il perché dovresti scegliere un modello rispetto all'altro:
Se un'entità (A) non ha senso caricarsi al di fuori del contesto di un'entità diversa (B), allora l'entità A dovrebbe probabilmente essere aggregata all'interno dell'entità B. Inoltre, nessuno dovrebbe fare riferimento a A in questo caso.
Solo perché esiste una relazione tra le tue entità non significa necessariamente che debbano essere aggregate.
Come esempio su un aggregato, una volta ho lavorato scrivendo un sito di lavoro online. Una delle caratteristiche era che una persona creava un CV e le aziende potevano cercare CV. Un CV conterrà un elenco di competenze (Una competenza in questo contesto significa qualcosa del tipo: "Sono molto abile in .NET, l'ho usato per 12 anni, l'ultimo nel 2012.) Non ha senso caricare una competenza in Ha senso solo nel contesto di un CV, anche se è possibile cercare CV corrispondenti a determinati requisiti di competenza, il risultato non sarebbe un elenco di competenze, ma un elenco di CV che soddisfano le competenze richieste. CV era una radice aggregata.
Ma termini come "Gruppo di applicazioni", "Applicazione" e "Configurazione" fanno veramente parte del tuo dominio o fanno parte dell'infrastruttura? Non sto dicendo che non potevano. Dipende ovviamente interamente dalla natura dell'applicazione a cui stai lavorando. Ma suona molto simile all'infrastruttura di sistema nelle mie orecchie.
Leggi altre domande sui tag repository-pattern domain-driven-design