我已经看了相当长一段时间的其他帖子，相对于聚合根。似乎我根本不明白如何以正确的方式定义聚合根。我看到诸如聚合根之类的答案可能不是聚合根，反之亦然。我有点困惑。问题是我脑子里有关系模型，但我知道 DDD 不会那样做。
有没有办法从关系模型中定义聚合根？
例如，如果您有一个包含日记条目的日记，每个日记条目都包含任务、问题和注释
您将如何定义聚合根？根是期刊吗？但如果您想访问笔记、问题和任务，这可能会导致问题。那么这些也聚合了引用日记帐条目的根吗？
它的东西很难理解，我想有更多的澄清。
谢谢。
问问题
1353 次
1 回答
4
我同意你的观点，聚合根的概念可能会令人困惑，直到你把它弄清楚。像大多数其他概念一样，它通过练习变得更容易，通过几次。
聚合的目的是在一个或多个用例的上下文中简化某些外部对象的对象遍历。您必须从某个地方开始以满足业务需求，并且如果您发现您在很大程度上需要一个 Journal，那么它实际上应该是一个聚合根。在大多数重要的领域中，您会发现拥有多个聚合根很有用。用例的起始对象没有什么超自然的。你只需要从某个地方开始。
但同样，重点是简化对象遍历，从而简化您的系统。因此，如果 Journal 实际上是一个有用的起点，请先调用 Journal。如果一个特定的用例最终需要任务、金钱、时间或任何其他有用的东西，调用程序会通过询问 Journal 来获取这些东西，并且只询问 Journal。对于此用例，其他对象是 Journal 聚合根的一部分。
对于其他用例，将 Task 作为起点可能更自然，因此也很有用，因此您可能也有一个 Task 聚合根，它可能会与用例的 Journal 聚合根重叠。但是您要求 Task 并且只有 Task 才能满足请求（成为调用程序需要知道的唯一参考）
您的关系数据库当然可以并且将保持关系。但是通过让您的对象模型演变为从聚合（起点对象）的角度查看请求，您来自数据库的请求最终会变得更简单。
布置一个（或两个）用例并尝试完成它。如果您愿意，可以在用例的上下文中提出问题。
HTH，
绿柱石
于 2011-01-31T06:48:07.677 回答