Identificazione delle entità figlio di progettazione guidata dal dominio

Question

Sto riscontrando qualche difficoltà nel capire in che modo la radice di aggregazione terrà traccia delle modifiche sulle entità figlio.

Let dire che ho un aggregato:

• Order (root)
• OrderLineItem

Con la classe Order essendo la radice di aggregazione. Come terrò traccia delle modifiche apportate su ciascuna delle OrderLineItem attraverso la classe Order?

Quando creo un repository (implementazione) ad es. un OrderRepository (perché solo la radice aggregata può avere il repository giusto?), come sarà il mio OrderRepository tracciare le modifiche di ogni OrderLineItem?

Esempio:

• appena aggiunto, ma non impegnati al DB
• modificato ma impegnata al DB
• cura, ma non impegnati al DB

Come si fa a ragazzi che fare con questo?

Answer 1

con la classe ordine che è la radice di aggregazione ora come farò a tenere traccia delle modifiche apportate su ciascuno dei OrderLineItem attraverso la classe Order?

Tutte le modifiche apportate all'aggregato Order, incluso OrderLineItem, devono passare attraverso la radice aggregata. In questo modo, l'aggregato può mantenere la sua integrità. Per quanto riguarda il monitoraggio delle modifiche, ciò dipende dall'implementazione della persistenza. Se si utilizza un ORM come EF o NHibernate, l'ORM si prenderà cura delle modifiche di tracciamento. Se si utilizza il sourcing di eventi, le modifiche vengono tracciate esplicitamente come una sequenza di eventi, generalmente gestita dall'aggregato nelle implementazioni OOP. Se si utilizza direttamente SQL, è anche possibile evitare le modifiche al monitoraggio e aggiornare l'intero aggregato su ogni commit.

e quando faccio un repository (applicazione) dire OrderRepository perché solo la radice aggregato può avere il diritto repository?

Sì, repository per aggregato.