DDD - Il repository di una radice aggregata gestisce il salvataggio degli aggregati?

Question

DDD - Il repository di una radice aggregata gestisce il salvataggio degli aggregati?

#1 da (22 voti)
#2 da (3 voti)

26

Sto usando un approccio tipo DDD per un modulo greenfield di un'applicazione esistente; non è DDD al 100% a causa dell'architettura, ma sto cercando di utilizzare alcuni concetti DDD. Ho un contesto limitato (penso che sia il termine corretto - sto ancora imparando a conoscere il DDD) composto da due Entità: Conversation e Message . La conversazione è la radice, poiché un messaggio non esiste senza la conversazione e tutti i messaggi nel sistema fanno parte di una conversazione.

Ho una classe ConversationRepository (anche se in realtà è più simile a un gateway, io uso il termine "Repository") che trova Conversazioni nel database; quando trova una conversazione crea anche (tramite le fabbriche) un elenco di messaggi per quella conversazione (esposti come una proprietà). Questo sembra essere il modo corretto di gestire le cose poiché non sembra esserci la necessità di una classe di% co_de in piena regola, poiché esiste solo quando viene recuperata una conversazione.

Tuttavia, quando si tratta di salvare un messaggio, è questa la responsabilità del ConversationRepository, poiché è la radice aggregata del messaggio? Quello che voglio dire è, dovrei avere un metodo su ConversationRepository chiamato, ad esempio, MessageRepository che accetta un messaggio come parametro e lo salva nel database? O dovrei avere un repository separato per trovare / salvare messaggi? La cosa logica sembra essere un repository per Entity, ma ho anche sentito "One repository per Context".

domain-driven-design architecture design-patterns

posta Wayne Molina 10.10.2011 - 14:41

fonte

2 risposte

3

Potresti creare ConversationService e iniettare IConversationRepository e IMessageRepository nel suo costruttore. Utilizza repository per operazioni CRUD semplici e servizi per tutto il resto (memorizzazione nella cache, salvataggio della logica, ecc.)

risposta data 10.10.2011 - 14:50

fonte

Leggi altre domande sui tag domain-driven-design architecture design-patterns

Perché XMLHttpRequest non sembra seguire una convenzione di denominazione? Git - Quali problemi nascono dal lavorare direttamente sul master?

score 22 · Accepted Answer

Il libro blu merita sicuramente una lettura se vuoi ottenere il meglio dall'approccio DDD. I pattern DDD non sono banali e imparare l'essenza di ognuno di essi ti aiuterà a riflettere su quando usare quale pattern, come dividere la tua applicazione in livelli, come definire i tuoi Aggregati e così via.

Il gruppo di 2 entità che stai citando non è un Contesto Limitato - probabilmente è un Aggregato. Ciascun Aggregato ha una radice aggregata, un'entità che funge da punto di ingresso singolo per l'aggregato per tutti gli altri oggetti. Quindi nessuna relazione diretta tra un'Entità e un'altra Entità in un altro Aggregato che non sia il Radice Aggregato.

I repository sono necessari per ottenere Entità che non sono facilmente ottenibili attraversando altri oggetti. I repository di solito contengono i Root aggregati, ma possono esserci anche Archivi di entità regolari.

Nel tuo esempio, Conversation sembra essere la radice di aggregazione. Forse le conversazioni sono il punto di partenza della tua applicazione, o forse vuoi interrogarle con criteri dettagliati in modo che non siano accessibili in modo soddisfacente attraverso il semplice attraversamento di altri oggetti. In tal caso è possibile creare un repository per loro che darà al codice client l'illusione di un insieme di conversazioni in memoria da cui eseguire query, aggiungere o eliminare direttamente. I messaggi d'altra parte si ottengono facilmente attraversando una conversazione e potresti non volerli ottenere secondo criteri dettagliati, solo tutti i messaggi di una conversazione in una sola volta, quindi potrebbero non aver bisogno di un repository.

ConversationRepository avrà un ruolo nei messaggi persistenti, ma non un ruolo così diretto come menzioni tu. Quindi, nessun AddMessage () su ConversationRepository (quel metodo appartiene piuttosto alla Conversazione stessa) ma invece, ogni volta che il Repository mantiene una Conversazione, è una buona idea mantenere i suoi Messaggi allo stesso tempo, in modo trasparente se si utilizza un framework ORM come (N) Hibernate, usando SQL ad hoc se lo si sceglie, ecc.