如何从关系模型定义聚合根以便将其用于 DDD？
我已经看了相当长一段时间其他关于聚合根的帖子。看来我根本不明白如何以正确的方式定义聚合根。我看到诸如聚合根之类的答案可能不是聚合根，反之亦然。我有点困惑。问题是我脑子里有关系模型，但我知道 DDD 不会那样做。
有没有办法从关系模型定义聚合根？
例如，如果您有一个日记，其中包含日记条目，其中每个日记条目都包含任务、问题和注释，
您将如何定义聚合根？根目录是期刊吗？但如果您想访问笔记、问题和任务，这可能会导致问题。那么这些也是引用日记帐分录的聚合根吗？
这很难理解，我想得到更多澄清。
谢谢。
Ive looked quite a while at others posts in there relativly to aggregates roots. It seem that i don't understand at all how to define in the right way aggregates roots. I saw answers such as aggregates roots might not be aggregates roots and vice versa. I am a bit confused. The problem is that i have relational model in head but i know that DDD won't go that way.
Is there a way to define aggregate roots from a relation model ?
Example, if you have a journal that hold journal entries which each hold tasks, problems, and notes
How would you define the aggregates roots ? Is the root a journal ? but that may cause problems if you want to access notes, problems and tasks. So are thoses also aggregates roots which hold reference to journal entries ?
Its something hard to understand and i would like to have some more clarification.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我同意你的观点，聚合根的概念可能会令人困惑，直到你弄清楚它为止。与大多数其他概念一样，通过练习几次，它会变得更容易。
聚合的目的是简化某个外部对象的对象遍历，在一个或多个用例的上下文中。您必须从某个地方开始来满足业务需求，如果您发现您主要需要一个日志，那么它实际上应该是一个聚合根。在大多数重要的领域中，您会发现拥有多个聚合根非常有用。用例的起始对象并没有什么超自然的。你只需要从某个地方开始。
但同样，重点是简化对象遍历，从而简化您的系统。因此，如果 Journal 实际上是一个有用的起点，请先向 Journal 拨打所有电话。如果一个特定的用例最终需要任务、金钱、时间或任何其他有用的东西，调用程序通过询问 Journal 来获取这些东西，并且仅询问 Journal。对于此用例，其他对象是日志聚合根的一部分。
对于其他用例，将任务作为起点可能更自然，因此也很有用，因此您也可能有一个任务聚合根，它可能会与用例的日记聚合根重叠。但是您要求任务并且仅要求任务来满足请求（是调用程序需要了解的唯一参考）
您的关系数据库当然可以并且将会保持关系。但是，通过让您的对象模型发展为从聚合（起点对象）的角度查看请求，来自数据库的请求将变得更加简单。
列出一个（或两个）用例并尝试解决它。如果您愿意，可以在用例的上下文中提出问题。
HTH，
贝里尔
I agree with you that the concept of aggregate roots can be confusing until you get your mind around it. Like most other concepts it gets easier with practice, working it through a few times.
The point of the aggregate is to simplify object traversal for some external obect, in the context of one or more use case(s). You have to start somewhere to satisfy a business requirement, and if you find that you are largely needing a Journal, it's like that it should in fact be an aggregate root. In most domains that aren't trivial, you will find it useful to have more than one aggregate root. There is nothing supernatural about the starting object for a use case. You just need to start somewhere.
But again, the point is to simplify object traversal, which simplifies your system. So if Journal is in fact a useful starting point, make all of your calls to Journal first. If a particular use case will wind up needing Tasks, Money, Time or any other useful things, the calling program gets those things by asking Journal, and only Journal. The other objects are part of the Journal aggregate root, for this use case.
For other use cases, it may be more natural and therefore useful for Task to be the starting point, and so you may have a Task aggregate root too, which will likely overlap your Journal aggregate root of use cases. But you ask Task and only Task to satisfy the request (be the only reference that the calling program needs to know about)
Your relational db can and will stay relational of course. But by having your object model evolve to look at requests from an aggregate (starting point object) point of view, your requests from the db will wind up being simpler.
Lay out a use case (or two) and try and work it through. Ask questions within the context of the use case if you like.
HTH,
Berryl