Concevez correctement la racine

Question

J'ai quelques problèmes pour concevoir la racine agrégée. Voici comment je le vois dans mon esprit:)

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..

Maintenant, sur cette base, ma racine globale serait le magasin. Cependant, si je devais maintenant créer un référentiel autour de cela, cela ressemblerait-il à ceci?

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

Est-ce un bon moyen de continuer? Inutile de dire que je suis nouveau sur DDD.

Answer 1

Je pense que vous devez considérer les limites globales et les entités comme quelque chose de plus qu'une simple hiérarchie. Les chances sont, vous aurez un modèle plus riche que cela.

La première façon de savoir si votre agrégat est correct est de pouvoir examiner chacune de ses entités et demander "Faut-il avoir directement accès à cela?" Si vous répondez oui, cette entité ne fait probablement pas partie de l'agrégat.

Sans en savoir plus sur votre domaine, je pourrais supposer que Store est bien un agrégat. Les ventes, en revanche, sont plus complexes. Oui, les ventes ont lieu dans un magasin, mais avez-vous besoin de regarder utiliser une vente de façon indépendante? Si vous en avez besoin en dehors du cadre du travail dans un magasin, Sales est probablement en dehors de cet agrégat.

J'imagine que les styles et les couleurs sont immuables et peuvent être répétés de sorte qu'ils seraient probablement des objets de valeur dans ce cas. Les zones sont-elles propres à un magasin ou varient-elles?

Personnellement, je trouve l’utilité d’identifier tous les éléments du domaine sur papier (ou sur un tableau blanc). Je vais passer par une phase de découverte avec la partie prenante et simplement la faire sortir. Ensuite, utilisez ces mots en tant que leaders dans la conversation, en essayant de comprendre leurs relations. Si vous interrogez suffisamment l'intervenant, la description qu'il donne définira en fait la plupart de ce que vous recherchez.

Ne pas battre un cheval mort, mais le livre Evans vaut vraiment la peine d’être lu / lu. C'est un peu sec, mais très perspicace. Pour un démarrage rapide, vous pouvez lire le livre gratuit sur InfoQ qui est fondamentalement un résumé du livre Evans.

Answer 2

Les racines agrégées sont des limites de cohérence pour les transactions, les distributions et les accès concurrents ( Eric Evans via Gojko Adzic ).

Lorsque deux personnes modifient différentes zones dans le même magasin, cela devrait-il provoquer un conflit de simultanéité? Sinon, les zones devraient peut-être avoir leur propre racine agrégée, séparée des magasins.

Answer 3

Il semble que " Store " La racine agrégée n’est pas parce que vous ne voulez pas masquer toutes les fonctionnalités de "Zones", "Ventes". etc derrière " Store " objet. De cette manière, & Store; Store " objet peut être très gonflé.

"Store", "Zone" et " Vente " pourrait avoir son propre référentiel.