正确设计聚合根

Question

我在设计聚合根时遇到了一些问题.这是我在脑海中看到的:)

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

现在基于此,我的聚合根将是商店.但是,如果我现在要围绕它创建一个存储库,它会是这样的吗？

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

这是继续下去的好方法吗？不用说我是DDD的新手.

Answer 1

我认为你需要将聚合边界和实体看作不仅仅是层次结构的东西.机会是,你将拥有比这更丰富的模型.

判断您的聚合是否正确的第一种方法是,您可以查看其中的每个实体并询问"这是否需要直接访问？" 如果您回答是,则该实体可能不是聚合的一部分.

如果不了解您的域名,我可能会认为Store确实是一个聚合.另一方面,销售更为复杂.是的,销售发生在商店,但您是否需要独立使用销售？如果您只是在使用商店的范围之外需要它们,那么Sales可能超出了该聚合.

我想象样式和颜色都是不可变的和可重复的,所以在这种情况下它们很可能是Value Objects.区域是商店独有的,还是它们有所不同？

就个人而言,我发现在纸上(或白板)识别域中的所有项目是有价值的.我将与利益相关者一起经历一个发现阶段,然后将它们带到那里.然后,使用这些词作为对话的领导者,试图理解它们之间的关系.如果您对利益相关者进行了充分的采访,他/她给出的描述实际上将定义您所寻找的大部分内容.

不要打败死马,但埃文斯的书绝对值得读/读.它有点干,但非常有见地.对于快速启动,您可以阅读InfoQ上的免费书籍,该书基本上是埃文斯书籍的摘要.

Answer 2

Aggregate Roots是事务,发行版和并发的一致性边界(Eric Evans通过Gojko Adzic).

当两个人在同一个商店中修改不同的区域时,是否会导致并发冲突？如果没有,那么也许Zones应该是他们自己的聚集根与商店分开.