领域驱动设计：如何处理概念上大的聚合根？答案

【问题标题】：Domain Driven Design: How to handle a conceptually large aggregate root?领域驱动设计：如何处理概念上大的聚合根？
【发布时间】：2014-05-23 10:28:19
【问题描述】：

我正在尝试对一个非常简单的域进行建模，该域具有概念上的 (one)PARENT --> (many)CHILD。问题是关系中的孩子数量可能有数百万。

我正在尝试构建一个聚合根，它允许我一次“放置”（如果不存在则更新或插入）一个孩子。但是，要更新的值必须由父级事先验证。

我可以使用哪些模式来解决这个问题？目前我考虑了以下几点：

PARENT 作为聚合根

+验证很简单，因为子级是通过父级访问的
-性能不佳，因为可能必须检索数百万个子项才能仅更新一个子项
+/- 我可以进行延迟加载吗？由于一致性问题，我阅读了很多文章，认为这是 DDD 反模式

CHILD 作为聚合根

+性能仅检索要更新的数据
- 验证因为非平凡，父必须是根的实体，或者根必须从外部提供给父以进行验证。这两个选项都会导致问题：
- 因为更新是“put”样式，第一个选项使创建子项变得困难（如果我在存储库的 find(id) 方法中实现创建，那么我没有构建子项的必要信息，并且如果我把它放在调用存储库的服务中，那么我没有办法访问父信息，因为它不是聚合根）。
- 第二个选项会导致一致性问题，即我可以提供一个不是正在更新的孩子的父级的父级。

两者都是聚合根

+/- 如何确保一致性，即子级由其实际父级验证？

【问题讨论】：

这个答案可能会帮助您做出决定：programmers.stackexchange.com/a/274404/149373

标签： validation domain-driven-design one-to-many aggregateroot

【解决方案1】：

您还没有理解什么是聚合根 (AR)。它不是孩子的父容器。 has 应该被处理为由定义的概念。一对多与识别 AR 无关。

“子”是一个在 AR 上下文中存在的概念，即它是由 AR 表示的聚合的一部分。您的示例似乎定义了一个存储库，一个项目容器。它看起来确实有点像 CRUD 功能。

你确定你是在一个聚合中，而不是在一个简单的服务就足够的上下文中吗？

【讨论】：

感谢您的回复。我还没有选择聚合根（这是我的问题的重点），所以我并不是在暗示关系中的父级应该是聚合根，因为它是一对多的关系。
不幸的是，由于它的业务敏感，我无法为您提供确切的场景，我想一个紧密的例子是尝试对大脑进行建模。大脑由数十亿个神经元组成，因此如果您将大脑作为您的 AR，您可能会遇到性能问题，因为当您想要激活大脑的某些行为时检索所有神经元是不可行的。如果我让神经元成为 AR，那么验证它的行为并不是一件容易的事，并且存在在大脑中创建新神经元的问题。哪个应该是 AR，还是应该有一些其他的 AR 来封装这些？
神经元是大脑的固有部分（afaik，生物学不是我的强项）。没有神经元，大脑就无法运作。那么，您的 AR 是否真的需要这些孩子有效，才能按照概念预期正常工作，或者它只是将事物结合在一起？你说的是取回东西。我认为您确实想要一个存储库，而不是 AR。使用适当的 AR 只检索 1 个孩子是没有意义的。它在需要什么用例时很重要。 DDD 建模中的事情并不简单，您需要确切地知道领域的含义。
顺便说一句，我们正在尝试对概念和用例进行建模，因为它们对业务有意义，而不是对业务或对象在现实生活中的准确描述。事情很棘手。
在大脑示例中，我暗示了多个有界上下文。 IE。在某些情况下，大脑是 AR。大脑问题不能仅由存储库来表示，因为它在您的概念模型中没有定义任何行为。假设在另一种情况下，我想调用一种需要了解一个神经元的大脑行为，比如说以一种非平凡的方式更新所述神经元的状态。您将如何以高效的方式对其进行建模，以避免检索大脑拥有的所有神经元？你的 AR 是什么？