6

我在设计聚合根时遇到了一些问题。这是我在脑海中的看法：）

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 的新手。

4

3 回答 3

7

我认为您需要将聚合边界和实体视为不仅仅是层次结构。很有可能，您将拥有比这更丰富的模型。

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

在不了解您的域的更多信息的情况下，我可能会认为 Store 确实是一个聚合。另一方面，销售则更为复杂。是的，销售发生在商店中，但您是否需要独立查看使用销售？如果您需要它们超出与商店合作的范围，Sales 可能不在该汇总范围内。

我想象样式和颜色都是不可变和可重复的，因此在这种情况下它们很可能是值对象。区域是商店独有的，还是有所不同？

就个人而言，我发现在纸（或白板）上识别域中的所有项目很有价值。我将与利益相关者一起经历一个发现阶段，然后让他们出去。然后，在对话中使用这些词作为领导者，试图了解它们之间的关系。如果您对利益相关者的采访足够好，他/她给出的描述实际上将定义您正在寻找的大部分内容。

不要打死马，但埃文斯的书绝对值得一读。它有点干，但非常有见地。为了快速入门，您可以阅读 InfoQ 上的免费书籍，它基本上是 Evans 书籍的摘要。

于 2009-10-28T20:22:15.413 回答
5

聚合根是事务、分布和并发的一致性边界（Eric Evans 来自 Gojko Adzic）。

当两个人修改同一个Store的不同Zone时，会不会造成并发冲突？如果不是，那么区域可能应该是它们自己的聚合根，与存储区分开。

于 2011-02-12T04:14:30.760 回答
2

似乎“商店”不是聚合根，因为您不想在“商店”对象后面隐藏“区域”、“销售”等的所有功能。这样，“Store”对象可能会非常臃肿。

“Store”、“Zone”和“Sale”可以拥有自己的存储库。

于 2009-10-28T20:17:50.773 回答