Progettare correttamente la radice aggregata

Question

Ho dei 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 in base a questo la mia radice aggregata sarebbe il negozio. Tuttavia, se ora dovessi creare un repository attorno a questo, sarebbe simile a questo?

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

È un buon modo per continuare? Inutile dire che sono nuovo di DDD.

Answer 1

Penso che sia necessario considerare i confini aggregati e le entità come qualcosa di più di una semplice gerarchia. È probabile che avrai un modello più ricco di quello.

Il primo modo per sapere se il tuo aggregato è corretto, è che puoi guardare ciascuna delle entità al suo interno e chiedere "È necessario accedere direttamente a questo?" Se rispondi sì, probabilmente tale entità non fa parte dell'aggregato.

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

Sto immaginando che sia gli stili che i colori siano immutabili e ripetibili, quindi probabilmente sarebbero oggetti valore in questo caso. Le zone sono esclusive di un negozio o variano?

Personalmente, trovo valore nell'identificare tutti gli elementi nel dominio su carta (o lavagna). Passerò attraverso una fase di scoperta con gli stakeholder e li farò uscire. Quindi, usa queste parole come leader nella conversazione, cercando di capire come si relazionano. Se intervisti abbastanza bene l'interessato, la descrizione che darà definirà effettivamente la maggior parte di ciò che stai cercando.

Per non battere un cavallo morto, ma vale sicuramente la pena leggere / leggere il libro di Evans. È un po 'secco, ma molto penetrante. Per un rapido avvio, puoi leggere il libro gratuito su InfoQ che è fondamentalmente un riassunto del libro di Evans.

Answer 2

Le radici aggregate sono limiti di coerenza per transazioni, distribuzioni e concorrenza ( Eric Evans via Gojko Adzic ).

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

Answer 3

Sembra che " Store " non è radice aggregata perché non desideri nascondere tutte le funzionalità per " Zone " ;, " Sales " ecc. dietro " Store " oggetto. In questo modo " Store " l'oggetto potrebbe essere molto gonfio.

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