Domain Driven Design: Quando per fare un aggregato Root?

Question

Sto cercando di implementare DDD per la prima volta con un progetto ASP.NET MVC e sto lottando con un paio di cose.

Ho 2 entità correlate, una società e un fornitore. Il mio primo pensiero è stato che la società era una radice di aggregazione e che il Fornitore è stato un oggetto di valore per la società. Così ho un repository per la società e nessuno per fornitore.

Ma, come ho iniziato a costruire la mia app, ho finito per dover lista separata, creo, e le forme di aggiornamento per il Fornitore. L'elenco è stato facile potevo chiamare Company.Suppliers, e creare era orribile potevo fare Company.Suppliers.Add (fornitore), ma l'aggiornamento mi sta dando un mal di testa. Dal momento che ho bisogno di una sola entità e non posso esattamente bastone in memoria tra le forme, ho finito per dover recupera nuovamente l'azienda e tutti i fornitori e trovare quello di cui avevo bisogno di legarsi ad esso e di nuovo per modificare e persistono esso indietro al db.

Ho solo bisogno di fare un getone se avessi un repository per fornitore. Potrei aggiungere alcuni arounds di lavoro con l'aggiunta di un GetOneSupplier alla mia Società o CompanyRepository, ma che sembra junky.

Quindi, sto veramente chiedendo se in realtà è un oggetto di valore, e non un'entità dominio completo in sé.

TLDR;

È necessitano lista separata / creare / aggiornare la vista / pagine un segno che un'entità dovrebbe essere di essa la propria radice?

Answer 1

In base alla terminologia Presumo che si sta eseguendo DDD basato sul libro di Eric Evans'. Suona come si è già identificato un problema con il tuo go iniziale a modellare e hai ragione su.

Si parla si pensava di fornitore come Value Object ... Suggerisco non lo è. Un Value Object è qualcosa in primo luogo identificato dalle sue proprietà. Ad esempio, la data "30 settembre, 2009" è un oggetto di valore. Perché? Perché tutte le istanze data con un diverso mese / giorno / anno combo sono date diverse. Tutte le istanze di data con lo stesso mese / giorno / anno combo sono considerati identici. Non avremmo mai discutere su scambiando la mia "30 Settembre 2009", per il vostro, perché sono gli stessi: -)

Un Entity d'altra parte è principalmente identificato dal suo "ID". Ad esempio, i conti bancari avere ID - hanno tutti i numeri di conto. Se ci sono due conti presso una banca, ciascuno con $ 500, se i loro numeri di conto sono diversi, lo sono anche loro. Le loro proprietà (in questo esempio, il loro equilibrio) non li identificano o implicano l'uguaglianza. Scommetto che avremmo discutere su scambiando conti bancari, anche se i loro saldi sono lo stesso: -)

Quindi, nel tuo esempio, vorrei prendere in considerazione un fornitore di un Entity, come io pretendo ciascun fornitore è principalmente identificato dal suo ID, piuttosto che le sue proprietà. La mia propria azienda condivide il nome con due altri nel mondo -. Eppure non sono tutti intercambiabili

Credo che la vostra idea che se hai bisogno di viste per CRUDing un oggetto, allora è una Entity probabilmente vale come regola generale, ma si dovrebbe concentrarsi di più su ciò che rende un oggetto diverso dagli altri:. Proprietà o ID

Ora per quanto Aggregate Roots andare, si vuole mettere a fuoco il ciclo di vita e controllare l'accesso degli oggetti. Considerate che ho un blog con molti posti ciascuno con molti commenti - in cui è / sono il Aggregate Root (s)? Cominciamo con i commenti. Ha senso avere un commento senza un post? Volete creare un commento, poi andare a trovare un post e allegare ad esso? Se si elimina un post, vuoi mantenere le sue osservazioni in giro? Suggerisco un post è un Aggregate Root con uno "foglia" - commenti. Consideriamo ora il blog stesso - il suo rapporto con i suoi messaggi è simile a quella tra post e commenti. E 'troppo a mio parere è un Aggregate Root con uno "foglia" -. Messaggi

Quindi nel tuo esempio, c'è una forte relazione tra azienda e fornitore per cui se si elimina una società (lo so ... probabilmente avete una sola istanza di società) si dovrebbe anche eliminare i propri fornitori? Se si elimina "Starbucks" (una società del caffè negli Stati Uniti) non tutti i fornitori del chicco di caffè cessano di esistere? Tutto questo dipende dal tuo dominio e l'applicazione, ma vi suggerisco più che probabile che nessuno di vostra Entities sono Aggregate Roots, o forse un modo migliore per pensare a loro è che sono radici di aggregazione ciascuno senza "foglie" (niente di aggregare). In altre parole, la società non controlla l'accesso o il controllo del ciclo di vita dei fornitori. Ha semplicemente una relazione uno-a-molti con i fornitori (o forse molti-a-molti).

Questo ci porta al Repositories. Un Repository è per memorizzare e recuperare Aggregate Roots. Hai due (tecnicamente non stanno aggregando nulla, ma la sua più facile che dire "repository memorizzano radici di aggregazione o enti che non sono foglie in un aggregato"), pertanto è necessario due Repositories. Uno per società e uno per i fornitori.

Spero che questo aiuta. Forse Eric Evans si nasconde qui intorno e mi dirà dove ho deviato dal suo paradigma.

Answer 2

Sembra un gioco da ragazzi per me - fornitore dovrebbe avere il proprio repository. Se non v'è alcuna possibilità logica che un'entità potrebbe esistere in modo indipendente nel modello allora dovrebbe essere un ente di root, altrimenti finirò a refactoring più tardi in ogni caso, che è il lavoro ridondante.

entità Root sono sempre più flessibile di oggetti di valore, nonostante i lavori di attuazione in più in attacco. Trovo che gli oggetti di valore in un modello diventano più rari nel corso del tempo come il modello si evolve, e le entità che rimangono gli oggetti di valore sono stati di solito quelli che si potrebbe logicamente vincolare in questo modo dal primo giorno.

Se i fornitori società per azioni poi avere il fornitore come entità radice rimuove la ridondanza dei dati e, in quanto non duplicare la definizione fornitore per società, ma condivide il riferimento, invece, e l'associazione tra azienda e fornitore può essere bidirezionale pure , che può produrre più benefici.