【问题标题】:Aggregates that require sharing of an entity需要共享实体的聚合
【发布时间】:2012-10-11 14:07:45
【问题描述】:

假设我的模型由两个聚合根 CustomerOrder 以及一个“共享”实体 Address 组成。

还要注意Addressabstract 具有以下子类:PhysicalAddressPostOfficeBoxAddressPrivateBagAddress

Customer 可以将许多地址组织成某种地址簿。 下订单后,客户会从他们的地址簿中选择一个Address 作为送货地址。

我最初的想法是在两个实体之间共享一个地址,但后来我选择了退出,因为这会给管理各自的不变量带来麻烦。

我可以选择的另一个选择是创建两个 Address 层次结构,每个层次结构都用作客户地址或送货地址。这又似乎不对,因为有很多重复的代码。

我将如何正确地模拟这种情况?

【问题讨论】:

    标签: language-agnostic domain-driven-design entity aggregate aggregateroot


    【解决方案1】:

    实体是应该能够自行存在的东西,例如客户或订单。但是,地址不是实体,地址是值类型,因此不能单独存在:

    1. 地址只能作为在实体中聚合的值类型存在
    2. 您可以将地址层次结构定义为域中的值类型,但许多实体可能会使用它。

    我们发现我们一直都会遇到这些类型的实体,例如 Address、MoneyType 等。

    解决方案是在您的域中创建 1 个地址层次结构值类型。然后任何实体都可以在适用的情况下将地址作为属性

    【讨论】:

    • 感谢您的回答,但似乎我无法使用我的 ORM 框架 JPA 来实现这一点。问题在于@Embeddables(值对象)无法利用继承。我将不得不寻找另一种解决方案。
    猜你喜欢
    • 2017-11-28
    • 1970-01-01
    • 2020-01-30
    • 1970-01-01
    • 2013-07-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-16
    相关资源
    最近更新 更多