Applicazione DDD al database Northwind

Question

Vorrei fare un po 'di esercizio e applicare DDD al mio modello di dominio applicato al database Northwind. Anche se Northwind è un esempio, immagino che sia stato fatto per soddisfare alcuni requisiti di "business virtuale". L'obiettivo è quindi avere un modello di dominio che rispetti il ​​DDD e i dati siano archiviati nel database di Northiwnd.

considerare questo modello EF persistenza:

alt text http://blogs.developpeur.org/blogs/tja/NorthwindModel_thumb_4FC6AF51.png

Avviso che abbiamo solo le entità e due rapporti vie. Mi piacerebbe avere un vero DM che rispetti il ​​DDD. Più, il mio modello DM non ha bisogno di essere lo specchio della mia banca dati

1. Come cambieresti des rapporti di avere un solo modo le relazioni o due modi quando necessario.

2. Esistono relazioni di molti a uno o uno a molti che possono essere modificate a una a una?

3. Come si modellerebbe gli aggregati?

4. Informazioni su Valori Oggetti, servizi e fabbriche se necessario?

So che probabilmente shoul guardo requisiti aziendali e che guarda come il modello dovrebbe cambiare, ma vorrebbe avere il vostro advaice su questo.

Non esitate a chiedere dettagli se la mia domanda non è chiara.

Grazie in anticipo.

Answer 1

In generale, sono tentato di rispondere a Mu (nel senso zen), perché lo scenario è sbagliato da una prospettiva DDD. In DDD iniziamo con i requisiti aziendali e gli esperti di dominio e da quelli deriviamo un modello di dominio .

Sebbene sia un punto controverso, il database è quasi solo un artefatto accessorio dei requisiti aziendali (che quasi sempre dichiara che le Entità devono essere mantenute).

Detto questo, cercherò di fare del mio meglio.

Nella maggior parte dei casi, un ordine è un oggetto business piuttosto importante, e ovviamente è necessario conoscere le righe dell'ordine, inclusi i prodotti in ogni riga, quindi sembrerebbe che ci sia bisogno dell'associazione dalla riga ordine (Order_Detail) al prodotto.

Tuttavia, quando viene fornito un determinato prodotto, raramente è necessario sapere in quali ordini è stato incluso, in modo da suggerire una relazione unidirezionale proprio lì. Possiamo navigare dalla linea d'ordine al prodotto, ma non dal prodotto alle righe d'ordine.

Tuttavia, l'analisi di cui sopra può rivelarsi falsa a un livello più profondo. Immaginate la seguente conversazione tra lo sviluppatore e l'esperto di dominio:

Dev:Abbiamo creato questa associazione da ordini di prodotti in modo che sappiamo sempre tutto ciò che riguarda i prodotti in un ordine particolare.

Exp:Che suona bene, ma per quanto riguarda il fornitore?

Dev:Anche questo è incluso.

Exp:Che cosa succede quando si cambia il fornitore per il prodotto?

Dev:Questo si rifletterà in modo implicito nei dati dell'ordine così ...

Exp:che non è quello che vogliamo. Vogliamo che i dati riflettano l'ordine al momento della spedizione.

In questo caso, risulta che c'è effettivamente un errore nello schema del database. Il problema può essere causato dalla segnalazione, perché gli analisti di business potrebbero voler eseguire report su come i diversi fornitori influenzano i guadagni (cosa ne so).

Tale caso può suggerire di tagliare l'associazione dalle righe di ordine al prodotto del tutto. Gli ordini devono contenere dati di prodotto storici (istantanee), non dati di prodotto attuali.

Possiamo anche entroduce un ProductSnapshotvalore dell'oggetto che rispecchia semanticamente un ProductEntity per modellare questo nel Modello di Dominio.

Tutto sommato, sembra sempre più ragionevole modellare Order come un aggregato di se stesso e linee di ordine (con ProductSnapShots), ma per quanto riguarda la relazione tra ordini e clienti?

Come attualmente comprendo associazioni e aggregati, le associazioni definiscono gli aggregati. Dato un ordine, vorremmo sapere del cliente? Più probabilmente. Dato un cliente, ti piacerebbe conoscere gli ordini? Probabilmente.

Questo suggerisce una relazione a due vie, che rende Customer la radice Aggregate. Ciò significa che avresti uno CustomerRepository, ma non lo OrderRepository. Ogni volta che hai bisogno di un ordine, devi farlo tramite lo Customer.

In alcuni casi questo può essere perfettamente sensato, mentre in altre situazioni questo potrebbe risultare molto goffo. Dipende molto dai requisiti aziendali ...

Si può anche considerare di creare un OrderRepository, ma questo invade il root di Customer Aggregate. Se lo fai, diventa vago dove si trova la responsabilità per l'Ordine. Cosa succede se si annulla l'ordine dal cliente? Customer ha un elenco di ordini, ma sono tutti compilati in memoria se si legge l'ordine dal OrderRepository?

Probabilmente no, ma è probabile che lo siano se si legge il Cliente dallo CustomerRepository.Il punto qui è che l'analisi di Root aggregati è importante e, una volta definito un aggregato, è necessario rispettarlo e rispettarlo.

Questo mi induce a favore piccoli aggregati oltre grandi aggregati, quindi in questo esempio, vorrei limitare l'aggregato al Order e le sue linee d'ordine, e non hanno alcuna associazione tra Order e Customer.

Non avendo un'associazione formale tra Order e Customer non significa che non possiamo riferire loro a tutti, ma abbiamo bisogno di esplicite servizi ci dà tutti gli ordini per un determinato cliente. Non possiamo semplicemente navigare da uno all'altro.