Recupero complesso di oggetti di dominio

2

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é:

  1. Ho un servizio per rappresentare le relazioni di entità.
  2. Sto dichiarando molte istanze di un servizio, mentre prima i servizi tendevano ad essere oggetti unici.
  3. 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.

    
posta SystematicFrank 19.07.2013 - 11:42
fonte

1 risposta

1

Penso che logica come questa dovrebbe entrare nel repository di un aggregato specifico. Vorrei mettere in discussione se Project e Task devono essere diverse radici aggregate. Le radici aggregate dovrebbero essere decise in base alle esigenze aziendali, non alla complessità (percepita). In entrambi i casi vorrei creare ProjectRepository::getTasks(project) o TaskRepository::getTask(project, taskId) . In questo modo, manterrai il numero di servizi al minimo mantenendo la logica laddove è logico cercarlo.

    
risposta data 19.07.2013 - 14:05
fonte

Leggi altre domande sui tag