正确设计聚合根

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

聚合根是事务，分布和并发的一致性边界（ Eric Evans via Gojko Adzic 。

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

Answer 3

似乎“存储”不是聚合根，因为您不想隐藏“区域”，“销售”和“销售”的所有功能。等等“商店”背后宾语。那样“存储”对象可能非常臃肿。

＆quot; Store＆quot;，＆quot; Zone＆quot;和“销售”可以拥有它自己的存储库。