在域之间共享值对象是个好主意吗？答案

【问题标题】：Is it a good idea to share valueobjects between domains?在域之间共享值对象是个好主意吗？
【发布时间】：2012-02-08 17:41:48
【问题描述】：

假设我们在系统中有两个域：Orderdomain 和 Customerdomain。

这两个域都相当复杂和庞大，因此不能将它们合并到一个域中。

但他们之间有业务关系。在每个订单上，客户都充当订购者。

我心中至少有三个解决方案。

将 customerId 作为原始类型存储在 Order 和 Customer 上。
创建两个值对象 OrderDomain.CustomerId 和 CustomerDomain.CustomerId。确保可以比较这些类型类型是否相等。
使用 valeobject CustomerId 创建第三个组件“SharedValueObjects”，并在两个域中使用该类型

哪个更受欢迎，或者你能想出第四个更好的吗？

【问题讨论】：

看起来当你说域时你指的是实体。问题尚不清楚，我认为您将实现细节与概念设计混合在一起。如果 Order 和 Customer 之间存在业务关系，则将该关系建模为一等公民。
不，我指的不是实体或聚合。我指的是不同的域。但是同样的问题也可以应用在那里，简单的答案是实体肯定可以共享相同的值对象类型。从我的角度来看，您不能仅在一个紧密耦合的领域中为大型企业建模。仅仅因为实体具有某种关系，它们就不能成为我世界上的一等公民。随着时间的推移，该领域模型将是一头野兽。
如何将客户与订单区分开来？一个没有另一个没有意义。没有客户的订单可以存在吗？如果不是，那它们怎么可能不在同一个域中？

标签： domain-driven-design value-objects

【解决方案1】：

我将尝试回答您关于值对象的一般问题以及您的 cmets 提出的更具体的问题？

域可以共享值对象吗？

这取决于。在我目前工作的系统中，我们有 15 个左右的大型服务，我们共享诸如“EMailAddress”、“PhoneNumber”、“Money”等值类型。这些类型定义明确，我们没有共享问题，但我不会仅仅因为它们可能在其他地方使用而共享东西，而是将您共享的值类型与实际使用的值类型共享。共享时，您需要为系统范围的耦合付出代价。

我是否会将客户与订单之间的关系公开为包装密钥的值对象？

不，我不会，正如其他人指出的那样，客户是在订单域工作的人会知道并需要数据的东西。如果您声称“客户”和“订单”代表两个不同的域，而不是我假设“客户”域类似于 CRM 数据？如果您将“客户”和“订单”分别建模而不是“客户”域不能包含您在“订单”域中所需的数据，例如账单地址。我理解您反对紧密耦合和庞大的对象图，但您可以通过确保系统中允许多个“客户”实体来处理这个问题；每个“客户”在有界上下文中代表自己的一组数据和行为。例如，您可以在您的 CRM 域中拥有一个客户实体，在您的“订单”域中拥有一个客户实体（我猜它实际上是一个订单域，因为“订单”听起来像是一个实体而不是一组封装的业务过程）。在您的 CRM 域中，客户可能有电话号码、联系人、邮政地址等内容，在“订单”域中，您的客户肯定会有订单以及帐单地址等内容。所以总结一下：不要创建一个拥有一切的客户，将其放在自己的域中并删除与订单的关系，您只是在减少对象图的大小。

【讨论】：

您将两个域所需的客户信息保存在哪里，例如“客户名称”？
两个域中的客户名称是否相同？例如：如果您更改了客户的姓名，如果查看之前的订单，是否应该反映更改？我会尝试寻找域差异，从而对两个域中的名称进行建模。注意：在报告或视图中使用数据并不表示您需要在两个域中复制数据。这也可能表明服务边界不佳。
如果它是相同的，它应该到处改变。比如修正错别字或其他原因？