Di solito ogni volta che voglio recuperare una radice aggregata per ID, uso solo un qualche tipo di funzione Repository :: findByID (...)
Ogni volta che ho iniziato con DDD ho pensato a fabbriche in cui solo un pattern per creare nuovi oggetti, ma dopo aver incontrato alcuni aggregati che necessitano di una o due query aggiuntive da caricare, mi sono reso conto che Factory :: objectWithID (. ..) sono stati utili anche per creare istanze di oggetti già esistenti nel database.
Ora ho una relazione ad albero di entità, come Progetto- > Attività . Il numero di relazioni è enorme e non ho una struttura che fornisce il carico pigro.
Poiché le attività possono essere nidificate, hanno una loro complessità e non devono essere completamente recuperate in una query, ho reso Progetto e Attività diverse radici aggregate
Come devo recuperare e persistere Attività ?. Sembra che ProjectFactory non sia la soluzione questa volta perché un progetto non contiene l'intero albero Attività .
Desidero ancora alcune funzionalità di base come aggregato per il mio progetto , e poiché sto evitando le query all'interno delle mie entità, ho deciso di scrivere le relazioni all'interno di un servizio di progetto-aggregato. Ora posso recuperare un singolo progetto con una funzione Repo :: findByID (), ma il recupero di un'attività è
ProjectAggregationService *service = ProjectAggregationService.new(SomeProject)
Task task_1 = service.findTask(...)
Task task_1_child_2 = service.findTaskChild(task_1,2)
Sono perplesso a questo punto perché:
- Ho un servizio per rappresentare le relazioni di entità.
- Sto dichiarando molte istanze di un servizio, mentre prima i servizi tendevano ad essere oggetti unici.
- Non avendo un albero degli oggetti chiaro come Project.tasks [1] .subtask [3] fai apparire il codice sopra più complesso del necessario.
Fondamentalmente potrei riassumere la mia domanda a: Ho preso l'approccio giusto?
Apprezzerei molto qualsiasi commento sul mio ragionamento. Sono principalmente preoccupato di degenerare il mio codice con una complessità eccessiva, ma continuo a pensare che mantenere i riferimenti a query e repository all'esterno dell'implementazione delle entità sia un buon obiettivo.