正确设计汇总根 [英] Design Aggregate Root Properly

问题描述

我在设计聚合根时遇到一些问题。这就是我的想法：）

I have some problems designing the aggregate root. Here is how I see it in my mind :)

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

现在基于此my聚合根将是商店。但是，如果我现在要围绕它创建一个存储库，它看起来像这样吗？

Now based on this my aggregate root would be the store. However if I were now to create a Repository around that, would it look something like this?

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

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

Is that a good way to continue? Needless to say that I am new to DDD.

推荐答案

我认为您需要查看汇总边界，实体不仅仅是层次结构。

I think you need to look at the aggregate boundaries and the entities as something more than just a hierarchy. Chances are, you will have a richer model than that.

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

The first way to tell if your aggregate is right, is that you can look at each of the entities within it and ask "Does this need to be directly accessed?" If you answer yes, then that entity is likely not a part of the aggregate.

如果不了解您的域名，我可能会认为Store确实是汇总。另一方面，销售更为复杂。是的，销售发生在商店中，但是您是否需要独立使用销售？如果您只需要在商店工作之外就需要它们，那么Sales可能不在该汇总范围之内。

Without knowing more about your domain, I might assume that Store is indeed an aggregate. Sales, on the other hand, are more complex. Yes, sales occur in a store, but do you have a need to look use a sale independently? If you need them outside of the scope of just working with a store, Sales is probably outside of that aggregate.

我在想样式和颜色都是不可变且可重复的，因此在这种情况下，它们很可能是Value Objects。区域是商店的唯一区域，还是各不相同？

I am imagining that both Styles and Colors are immutable and repeatable, so they would likely be Value Objects in this case. Are Zones unique to a store, or do they vary?

我个人认为，在纸上（或白板）域中标识所有项目很有价值。我将与利益相关者一起进行发现阶段，然后将他们带到那里。然后，将这些单词用作对话中的领导者，试图了解它们之间的关系。如果您对利益相关者进行了足够的访谈，那么他/她所提供的描述实际上将定义您所寻找的大部分内容。

Personally, I find value in identifying all of the items in the domain on paper (or whiteboard). I will go through a discovery phase with the stakeholder and just get them out there. Then, use these words as leaders in the conversation, trying to understand how they relate. If you interview the stakeholder well enough, the description he/she gives will actually define most of what you are looking for.

不是要击败一匹死马，而是要击败埃文斯这本书绝对值得一读。有点干，但是很有见地。为了快速起步，您可以在InfoQ上阅读免费书基本上是埃文斯著作的摘要。

Not to beat a dead horse, but the Evans book is definitely worth getting/reading. It is a little dry, but very insightful. For a quick jumpstart, you can read the free book up on InfoQ that is basically a summary of the Evans book.

这篇关于正确设计汇总根的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！