定义聚合根和那时之间的关系
我正在学习 DDD，并想开始对一个相当简单的示例（博客应用程序）进行建模。
我有点困惑的一个领域是定义聚合根。
到目前为止，这是我的模型：
Site
has many
Blog
has reference to Site
has many
Post
has reference to Blog
has Category
has many
Comments
在这个例子中，我唯一确定的是 Comment 是一个值对象，因为它在帖子的上下文之外没有任何意义。
但随后基于：
通过数据库查询只能直接获取聚合根。 其他一切都必须通过遍历来完成。
我倾向于制作站点、博客和帖子 AR，因为我希望直接获取它们，而不是遍历集合。
我意识到博客并不完全是一个复杂的域模型，因此并不真正保证应用 DDD，但我只是想了解如何对这些类型的关系进行建模。
I'm learning DDD and wanted to start modelling a fairly trivial example, a blog application.
One area I'm a little confused about is defining aggregate roots.
Here's my model so far:
Site
has many
Blog
has reference to Site
has many
Post
has reference to Blog
has Category
has many
Comments
In this example the only thing I am sure of is that Comment is a value object since it makes no sense outside the context of a post.
But then based on:
Only Aggregate Roots can be obtained directly with database queries.
Everything else must be done through traversal.
I would be inclined to make Site, Blog and Post ARs since I would want to obtain them all directly rather than traversing a collection.
I realize that a Blog isn't exactly a complex domain model so doesn't really warrant applying DDD but I just want to understand how these type of relationships are modelled.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
并不是因为您有层次结构，所以您必须定义聚合。如果您在层次结构中需要维护不变量，那么聚合构造会很方便。
在您的示例中，假设您希望博客中的每个帖子都有一个唯一的“slug”（Wordpress 样式，以便标题出现在 URL 中）。只有“博客”实体可以强制执行此不变量。同样，在这种情况下，将其聚合并通过博客实体添加帖子是有意义的。
另一个例子：您的网站可以是公共的，也可以是私人的。这是站点实体的属性。因此，您必须确保使用从聚合根（即站点）进行遍历来访问帖子，因为只有站点才能授权您或不访问底层对象。
如果您将该网站设置为聚合根，则最终可能会得到如下网址：
http://site.com/ myblog/apost
您的代码将首先检索站点实体，从该实体获取博客，然后从博客实体获取帖子。如何检索子实体取决于您。此模型不会强制您在检索站点时将所有博客文章加载到内存中。它只是强制您从网站检索博客以及博客中的帖子。
It is not because you have a hierarchy that you must define an aggregate. The aggregate construct will come handy if you have invariant to maintain within the hierarchy.
In your example, assume that you want each post in a blog to have a unique 'slug' (Wordpress style, so that the title appears in the URL). Only the 'Blog' entity can enforce this invariant. Similarly, in that case it would make sense to make it the aggregate and have the post added via the blog entity.
Another example: your site can be public or private. This is an attribute of the Site entity. You must therefore make sure to access to a post using traversal from the aggregate root which would be the site since only the site can authorize you or not to access the underlying objects.
If you make the site the aggregate root, you could end up with an url like this:
http://site.com/myblog/apost
Your code would first retrieve the site entity, from that entity it gets the blog, and from the blog entity it fetch the post. How you go about retrieveing the child entities is up to you. This model does not force you to load all blog posts in memory when retrieving the site. It just force you to retrieve the blog from the site, and the posts from the blog.