我在其他帖子中看了很长一段时间，相对于聚合根源。似乎我完全不了解如何以正确的方式定义聚合根。我看到聚合根的答案可能不是聚合根，反之亦然。我有点困惑。问题是我有头脑中的关系模型，但我知道DDD不会这样。
有没有办法从关系模型中定义聚合根？
示例，如果您有日记 保留日记条目 每个日记条目
您如何定义聚合根？根是期刊吗？但如果您想访问笔记，问题和任务，这可能会导致问题。那么，那些也会聚集根据日记帐分录的根源吗？
它很难理解，我希望得到更多澄清。
感谢。
答案 0 :(得分：4)
我同意你的观点，在你深入思考之前，聚合根的概念可能会令人困惑。像大多数其他概念一样，通过练习可以更轻松地完成它。
聚合的要点是简化一个外部对象的对象遍历，在一个或多个用例的上下文中。您必须启动某处以满足业务需求，如果您发现自己很需要日记帐，那么它实际上应该是一个聚合根。在大多数不重要的域中，您会发现拥有多个聚合根很有用。用例的起始对象没有任何超自然现象。你只需要从某个地方开始。
但同样，重点是简化对象遍历，这简化了系统。因此，如果Journal实际上是一个有用的起点，请首先调用Journal。如果一个特定的用例最终需要任务，金钱，时间或任何其他有用的东西，那么调用程序通过询问Journal而不是Journal来获取这些东西。对于此用例，其他对象是Journal聚合根的一部分。
对于其他用例，它可能更自然，因此将Task作为起点可能更有用，因此您也可能有一个Task聚合根，这可能会与您的Journal聚合用例根重叠。但是你要求Task和only Task来满足请求（是调用程序需要知道的唯一参考）
您的关系数据库当然可以并且将保持关系。但是，通过让对象模型发展为从聚合（起始点对象）的角度来看待请求，来自数据库的请求将变得更简单。
布置一个用例（或两个）并尝试通过它。如果您愿意，可以在用例的上下文中提问。
HTH，
Berryl