un repository per ogni entità di aggregazione radice nella progettazione basata su domini

Question

Se si segue il modello di repository essi ... dicono di creare un repository per ogni entità di aggregazione radice.

Ciò significa che quando ho questo modello:

cliente ha ordini ordine ha prodotti prodotto ha il fornitore

ecc ...

Ciò significherebbe Ho 4 repository che vengono messi in UN REPO. il cliente è l'entità radice.

Ho frainteso qualcosa qui?

Answer 1

È corretto che sia necessario un repository per aggregato. Ciò che può variare, tuttavia, è l'insieme di aggregati nel tuo dominio. Il modello Cliente/Ordine/Prodotto/Fornitore può essere scomposto in aggregati in diversi modi. La scomposizione in aggregati dipende da una varietà di fattori ed è dipendente dal dominio in questione.

Un aggregato deve essere un limite di coerenza che significa che definisce quale insieme di entità deve essere coerente nel contesto di comportamenti associati a tali entità. Dato questo vincolo, i riferimenti agli oggetti tra aggregati dovrebbero essere eliminati e sostituiti con riferimenti di identità.

Nel modello, potrebbe essere che cliente, ordine, prodotto e fornitore siano aggregati distinti e richiederebbero quindi repository separati. Anche se il cliente è una radice aggregata (parte dell'aggregato del cliente) e l'ordine dipende dal cliente, ciò non significa che il repository del cliente debba contenere il repository degli ordini. Il repository degli ordini dovrebbe essere completamente separato, poiché l'ordine è una radice dell'aggregazione dell'ordine.

Dai uno sguardo allo Effective Aggregate Design by Vaughn Vernon per un trattamento approfondito su come progettare gli aggregati.

Answer 2

Hai 4 entità correlate come hai delineato sopra e il repository implementa il contesto della transazione per tutte quelle entità correlate.