Design Aggregate Root Proper

Question

Ho alcuni problemi nella progettazione della radice aggregata. Ecco come lo vedo nella mia mente :)

Store (the aggregate root) 
-> Sales - A store create a sale every day 
-> Zones - A store is divided into zones 
    -> Styles - A zone has x number of styles 
     --> Colors - A style has x number of colors 
    etc.. 

Ora basato su questo la mia radice aggregata sarebbe il negozio. Tuttavia, se dovessi creare un repository, sarebbe simile a questo?

public class StoreRepository() 
{ 
    Store GetById() {...} 
    StoreZone GetZone() {...} 
    List<StoreZoneStyle> GetStylesByZone() {...} 
    List<Color> GetColorsByStyle() {...} 
} 

è che un buon modo per continuare? Inutile dire che sono nuovo del DDD.

Answer 1

Penso che avete bisogno di guardare ai confini aggregati e gli enti come qualcosa di più di una gerarchia. Le probabilità sono, avrai un modello più ricco di quello.

Il primo modo per sapere se il vostro aggregato è giusto, è che si può guardare in ciascuna delle entità all'interno di esso e chiedere: "Questo bisogno di accedere direttamente?" Se rispondi sì, allora quell'entità probabilmente non fa parte dell'aggregato.

Senza sapere di più sul tuo dominio, posso presumere che lo Store sia effettivamente un aggregato. Le vendite, d'altra parte, sono più complesse. Sì, le vendite si verificano in un negozio, ma hai bisogno di cercare di utilizzare una vendita in modo indipendente? Se ne hai bisogno al di fuori dello scopo di lavorare solo con un negozio, le vendite sono probabilmente al di fuori di tale aggregato.

sto immaginando che entrambi gli stili e colori sono immutabili e ripetibile, in modo che sarebbe probabilmente oggetti di valore in questo caso. Le Zone sono uniche per un negozio o variano?

Personalmente, trovo il valore per identificare tutti gli elementi nel dominio su carta (o lavagna). Passerò attraverso una fase di scoperta con gli stakeholder e li porteremo là fuori. Quindi, usa queste parole come leader nella conversazione, cercando di capire come si relazionano. Se intervisti lo stakeholder abbastanza bene, la descrizione che lui/lei dà in realtà definirà la maggior parte di ciò che stai cercando.

Non per battere un cavallo morto, ma il libro di Evans merita sicuramente di essere letto/letto. È un po 'secco, ma molto perspicace. Per un rapido avvio, puoi leggere lo free book su InfoQ che è fondamentalmente un riassunto del libro di Evans.

Answer 2

Sembra che "Store" non è radice di aggregazione, perché non si vuole nascondere tutte le funzionalità per "Zone", "vendite", ecc dietro oggetti "Store". In questo modo l'oggetto "Store" potrebbe essere molto gonfio.

"Store", "Zone" e "Vendita" potrebbe avere il proprio repository.

Answer 3

I root aggregati sono limiti di coerenza per transazioni, distribuzioni e concorrenza (Eric Evans via Gojko Adzic).

Quando due persone modificano Zone diverse nello stesso Archivio, ciò dovrebbe causare un conflitto di concorrenza? In caso contrario, forse le Zone dovrebbero essere la loro radice di aggregazione separata dai negozi.