【问题标题】:DDD modeling, interaction between aggregate rootsDDD 建模,聚合根之间的交互
【发布时间】:2010-08-20 16:35:38
【问题描述】:

用 1;2;3 标记了我的聚合根。看起来很不错——几乎像葡萄。

我不喜欢的是带有红色箭头的实体。

让我们想象一下:

  • AR #1 是公司
  • AR #2 是办公室
  • AR #3 是员工
  • 用红色箭头标记的实体名为Country
    • 公司制定了从哪些国家/地区雇用员工的规则(在雇用时,company.Countries.Contains(employee.Country) 必须为真)

我以某种方式看到了域中这个相当不重要的部分(也许在这个示例中听起来不像),并且我想避免将 Country 提升为聚合根。

Glossary 关于聚合根 说:

对内部成员的临时引用只能在单个操作中使用。

那么 - 引入诸如“EmployeeCountry”之类的内容、删除对公司 Country 的引用并检查 Employee country 在招聘操作中是否与任何公司所在国家/地区相匹配听起来合理吗?

还有其他想法吗?

我怎样才能让我的葡萄看起来像他们应该的样子?

【问题讨论】:

    标签: domain-driven-design modeling aggregateroot


    【解决方案1】:

    在这种情况下,Country 只是一个值对象,而不是一个实体——更不用说聚合根了——所以没有理由改变你的设计(没有更多信息)。

    另外,请注意您引用的警告与聚合根的内部成员有关,而不是聚合本身。在多个地方维护对聚合的引用并没有错。聚合根应该封装子对象,以便在一个地方执行相关对象的业务规则。

    您可以在 Evans 的“领域驱动设计”(又名“The Blue Book”)的几个地方清楚地看到这一点。例如,请参阅第 127 页上的图表(在聚合根的介绍中),它显示了一个 Car 聚合,它引用了一个 Engine 聚合。

    【讨论】:

    • 那到底发生了什么变化?提供更多细节。 :)
    • 嘿,抱歉这么简洁。我也在提示您提供更多详细信息。 :) 我的立场是,正如您所描述的那样,您的设计没有任何问题。你不喜欢你目前的设计什么?为什么您认为您可能需要将国家/地区提升为聚合根?
    • 原因 2 聚合根不应引用同一实体。这不是正确的吗?值对象不一样?
    • 引用同一个实体的 2 个聚合根没有问题 - 它们只是不能引用另一个聚合的 internals。对于更简单的值对象,情况有所不同。考虑如何在课堂上多次引用日期,例如“2010 年 8 月 20 日”。肯定有应用程序(或有界上下文),其中国家应该是封装子对象和业务逻辑的成熟实体,但根据您的描述,这不是其中之一。
    • 对我来说听起来不错。只需要确保它们在持久性级别也充当值对象。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-03-21
    • 2020-01-30
    • 1970-01-01
    • 2019-08-13
    • 1970-01-01
    相关资源
    最近更新 更多