Domain Driven Design - Radici aggregate quando tutti i dati sono necessari dal nodo figlio

Question

Domain Driven Design - Radici aggregate quando tutti i dati sono necessari dal nodo figlio

#1 da (2 voti)
#2 da (1 voti)

2

Sto lottando con un concetto di DDD nella progettazione di radici aggregate. Ho un cliente, che ha più progetti, i progetti hanno più incarichi di progetto, che ha più dipendenti. Sembra naturale avere un ClientRepository, che gestisca Project, e non esporre un ProjectRepository. Dopotutto un progetto deve appartenere a un cliente. Ma ... gli affari arrivano a lungo e vogliono una pagina che mostri tutti i progetti, indipendentemente dal cliente. Fondamentalmente un dump della tabella Project. Non c'è modo di ottenere tutti i Progetti da ClientRepository o dall'oggetto ClientDomain stesso, quindi esponi un ProjectRepository in quel caso?

Solo per lo sfondo il mio stack tecnologico è Java, Spring, Spring-Data-JPA, Hibernate, sebbene DDD sia indipendente dalla tecnologia.

design domain-driven-design domain-model domain-objects

posta jkratz55 21.02.2017 - 21:46

fonte

2 risposte

Leggi altre domande sui tag design domain-driven-design domain-model domain-objects

Scelta tra API Web e riferimento DLL Usa struct oppure no

score 2 · Answer 1

Potresti voler esaminare i concetti dei modelli di lettura, possibilmente in combinazione con un'architettura in stile CQRS per il tuo contesto vincolato che tratta di clienti e progetti.

L'aggregato che contiene la logica di business sarebbe un cosiddetto modello di scrittura con la responsabilità di cambiare lo stato nel sistema preservando gli invarianti di business.

L'effetto di tali cambiamenti è una questione di implementazione e può variare dalla modifica dei dati in memoria al salvataggio dei dati in un database. O aggiungendo eventi a un registro eventi che verrà successivamente utilizzato per ripristinare lo stato se l'aggregato (event sourcing).

Avere un meccanismo di eventi (non necessariamente associato al sourcing di eventi) abilita gli aggiornamenti dei modelli di lettura che verranno utilizzati per recuperare i dati per uso esterno es. in un'interfaccia utente dell'applicazione.

Sebbene possa esistere un solo modello di scrittura per garantire l'integrità delle regole aziendali, potrebbero esserci più modelli di lettura che possono essere aggiornati da varie fonti.

Detto questo, anche un database relazionale può essere utilizzato per ottenere alcuni dei vantaggi della separazione tra modelli di scrittura e lettura. Ad esempio, puoi avere uno schema altamente normalizzato per le scritture e creare viste denormalizzate per avere un modello diverso per l'accesso in lettura.

score 1 · Answer 2

Penso che secondo DDD non sia un problema raccogliere tutti i Progetti tramite il ClientRepository per visualizzarli in una vista (di sola lettura). ClientRepository non può caricare direttamente i progetti, quindi è necessario caricare e attraversare tutti i client e raccogliere i loro progetti.

Si noti che la vista non è autorizzata a eseguire il trigger (diretto) Modifiche al progetto. Qui è necessario l'oggetto radice aggregato di Progetti o rendere Project una radice aggregata.

In alcuni casi potrebbe anche essere completamente ok ignorare DDD e accedere direttamente ai tuoi progetti (tramite SQL, ad esempio). Ovviamente anche qui la vista dovrebbe essere di sola lettura.