在DDD中，哪一种是分离聚合的最佳方法？

Question

我正在学习DDD，我不清楚如何将对象分离成聚合。

一个例子：

我有三个目标:公司，商店，工作。

我有一些关系:一家公司有很多商店，一家商店有很多工作。

I认为：

没有公司，商店就不可能存在。一家公司必须有商店，这是真实的世界。所以，我把公司和商店组合成一个整体。

工作是另一个集合。

另一种思想--

在找工作的时候，我总是关心这份工作属于哪一家商店。所以，我把:商店和工作合并成一个整体。

公司是另一个集合。

哪条路是对的？

谢谢

Answer 1

当然，唯一可能的答案是，"It取决于.“，但这并不特别有用。

回顾Evan书中关于聚合的定义：

聚合是一个关联对象的集群，我们将其作为一个单元来处理数据更改。不变量是数据更改时必须维护的一致性规则，它将涉及聚合成员之间的关系。任何跨越集合的规则都不会被期望在任何时候都是最新的.但是，在聚合中应用的不变量将随着每个事务的完成而强制执行。

因此，“什么对象构成了我的聚合”和“我的聚合根是什么？”取决于哪些业务不变量需要在哪个业务事务之间强制执行？

您不像在关系数据库中设计表那样设计聚合。在“现实生活”中，你并不关心实体之间的多重关系。您正在寻找哪些事实(属性、值)在影响(变异)这些实体的数据的操作结束时必须为真。

看看你的要求。看看您的系统需要支持什么样的行为。你能用工作做什么？创造他们？启动他们？完成它们？你能把工作从一家商店转到另一家商店吗？一份工作能在公司之间调动吗？

哪些事实需要保持一致？你是否在实施每家商店的最大数量的工作？在“添加作业”结束时，商店中当前的#工作是否需要与作业的分配保持一致？

由于您只能通过它的根与聚合交互，所以您需要考虑如何添加新数据的上下文。你能在没有最初的商店任务的情况下创造一个工作吗？或者只能通过商店来创造？

在更新事务中的聚合时，聚合的大小/范围与数据争用的可能性之间也存在折衷。

考虑到所有这些需要担心的事情，您可能会想，为什么还要使用聚合呢？嗯，他们在几件事上很棒：

• 命令的验证和执行是快速的，因为您需要的所有数据都是聚合中的自包含数据。
• 它们很好地利用了基于文档的持久性存储(比如用于聚合对象的嵌套文档的MongoDB )，这使得对聚合状态的检索变得简单和高效，并且通过文档级原子更新可以轻松地执行聚合事务边界。
• 它们非常容易测试，因为它们可以实现为简单的类( C#或Java中的POCO/POJO)。因为它们包含了大部分业务逻辑，这意味着您的整个应用程序的行为也很容易进行单元测试！
• 它们是有意的；每个聚合都有其目的，从它们在系统中实现的数据和函数可以很清楚地看出它们所做的事情。再加上在代码本身中使用无处不在的上下文语言，它们是代码库中最直接的业务行为表示(远远超过一组数据表)。
• 由于它们是如此特定于用例，聚合通常避免出现在更通用的解决方案中的泄漏抽象。

如果你对阅读更多感兴趣，沃恩·弗农( Vernon )在他的有效集料设计文章中有一个很好的总结，这是他的“实现领域驱动设计”()一书的基础。