DDD建模，聚合根之间的交互
用 1;2;3 标记我的聚合根。看起来很漂亮——几乎像葡萄。
我不喜欢的是一个用红色箭头标记的实体。
让我们想象一下：
- AR #1 是公司
- AR #2 是办公室
- AR #3 是员工
- 用红色箭头标记的实体名为
Country- 公司制定从哪些国家/地区雇用员工的规则（在雇用时，
company.Countries.Contains(employee.Country)必须为 true）
- 公司制定从哪些国家/地区雇用员工的规则（在雇用时，
我以某种方式认为域的这个相当不重要的部分（也许在这个例子中听起来并不像1），我想避免将国家推广为聚合根。
关于聚合根的词汇表说：
对内部成员的临时引用只能传递出去以供在单个操作中使用。
那么，引入“员工国家/地区”之类的内容、删除对公司国家/地区的引用并检查员工所在国家/地区是否与招聘操作中的任何公司国家/地区相匹配，听起来合理吗？
还有其他想法吗？
我怎样才能让我的葡萄看起来像应有的样子？
Marked my aggregate roots with 1;2;3. Looks quite nice - almost like grapes.
Thing I dislike is an entity that's marked with red arrow.
Let's imagine that:
- AR #1 is company
- AR #2 is office
- AR #3 is employee
- Entity marked with red arrow is named
Country- Company sets the rules from which countries it hires employees (on hiring,
company.Countries.Contains(employee.Country)must be true)
- Company sets the rules from which countries it hires employees (on hiring,
I somehow see this quite unimportant part of domain (maybe it does not sound like that in this example one), and I would like to avoid promoting Country to aggregate root.
Glossary about aggregate roots says:
Transient references to the internal members can be passed out for use within a single operation only.
So - does introducing something like 'EmployeeCountry', removing reference to company Country and checking if Employee country matches any company country on hiring operation sounds reasonable?
Any other ideas?
How can I get my grapes look like they should?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这种情况下，
Country只是一个值对象，而不是一个实体 - 更不用说聚合根 - 因此没有理由更改您的设计的任何内容（没有更多信息）。此外，请注意，您引用的警告涉及聚合根的内部成员，而不是聚合本身。在多个地方维护对聚合的引用并没有什么问题。聚合根应该封装子对象，以便有一个地方可以为相关对象强制执行业务规则。
您可以在 Evans 的“领域驱动设计”（又名“蓝皮书”中的多个地方清楚地看到这一点） ）。例如，请参阅第 127 页上的图表（在聚合根的介绍中），该图显示了具有对 Engine 聚合的引用的 Car 聚合。
In this context
Countryis just a value object, not an entity - much less an aggregate root - so there's no reason to change anything about your design (without more information).Additionally, note that the warning you cite pertains to internal members of aggregate roots, not aggregates themselves. There's nothing wrong with maintaining references to aggregates in multiple places. Aggregate roots are supposed to encapsulate child objects so that there's a single place to enforce business rules for related objects.
You can see this clearly in several places in Evans' "Domain-Driven Design" (a.k.a., "The Blue Book"). For example, see the diagram on page 127 (in the introduction to aggregate roots), which shows a Car aggregate that has a reference to an Engine aggregate.