Come gestisci le associazioni tra aggregati in DDD?

Question

Sto ancora avvolgendo la mia mente su DDD, e uno degli ostacoli che ho incontrato è su come gestire le associazioni tra aggregati separati. Supponiamo che io abbia un aggregato che incapsula i clienti e un altro incapsulare le spedizioni.

Per motivi aziendali Le spedizioni sono i propri aggregati e tuttavia devono essere esplicitamente legate ai clienti. La mia entità di dominio cliente dovrebbe avere un elenco di spedizioni? In tal caso, come faccio a popolare questo elenco a livello di repository, dato che avrò un CustomerRepository e un ShipmentRepository (un repository per aggregato)?

Sto dicendo "associazione" piuttosto che "relazione" perché voglio sottolineare che si tratta di una decisione di dominio, non di un'infrastruttura - sto progettando il sistema prima dal modello.

Edit: so che non è necessario modellare le tabelle direttamente sugli oggetti: è questa la ragione per cui sto progettando il modello per primo. A questo punto non mi interessa affatto il database - solo le associazioni tra questi due aggregati.

Answer 1

Non c'è motivo per cui il tuo repository di spedizione non possa aggregare i dati dei clienti nei tuoi modelli di spedizione. I repository non devono avere un mapping 1-a-1 con le tabelle.

Ho diversi repository che combinano più tabelle in un modello di dominio singolo.

Answer 2

Penso che ci siano due livelli di risposta a questa domanda. Ad un livello, la domanda è: come faccio a popolare la relazione tra cliente e spedizione. Mi piace molto la semantica di "riempimento" in cui il repository delle spedizioni può avere un riempimentoOrders (Elenco dei clienti, ....).

L'altro livello è "come gestisco i modelli di dominio denormalizzati che fanno parte di DDD". E "Cliente" è probabilmente il miglior esempio di tutti, perché si presenta semplicemente in così tanti contesti diversi; quasi tutti i tuoi processi hanno clienti in loro e il contesto del cliente è di solito estremamente vario. Alla metà del tempo sei interessato agli "ordini". Se la mia comprensione del dominio era perfetta all'avvio, avrei mai creare un concetto di dominio del cliente. Ma non lo è, quindi finisco sempre per rendere il Cliente oggetto. Ricordo ancora il progetto in cui I dopo 3 anni ritenevo di essere in grado di creare il modello di dominio "Cliente" corretto. I sarebbe essere alla ricerca di concetti alternativi e più dettagliati che rappresentano anche il cliente; Potenziale Clienti, OrderingCustomer, CustomerWithOrders e probabilmente pochi altri; scusa, i nomi non sono migliori Avrò bisogno di più tempo per quello;)

Answer 3

La spedizione ha una relazione molti-a-uno con il Cliente. Se stai cercando le spedizioni di un cliente, aggiungi una query al tuo repository di spedizione che accetta un parametro client.

In generale, non creo associazioni univoche tra entità quando il lato più non è limitato.