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

Question

让\xc2\xb4s 假设我们\xc2\xb4 在系统中有两个域：Orderdomain 和Customerdomain。

\n\n

这两个域都相当复杂且庞大，因此将它们合并到一个域中并不是一种选择。

\n\n

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

\n\n

我脑子里至少有三个解决方案。

\n\n

\n

1. 将 customerId 作为原始类型存储在 Order 和 Customer 上。

\n

2. 创建两个值对象 OrderDomain.CustomerId 和 CustomerDomain.CustomerId。确保可以比较这些类型的相等性。

\n

3. 使用 valeobject CustomerId 创建第三个组件“SharedValueObjects”，并在两个域中使用该类型

\n

\n\n

哪一个是首选，或者您能想出第四个更好的吗？

\n

Answer 1

我将尝试回答您关于价值对象的一般问题以及您的评论中更具体的问题？

1. 域可以共享值对象吗？

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

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

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