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

Question

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

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

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

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

1. 在订单和客户上将customerId存储为基本类型。

2. 制作两个valueobjects OrderDomain.CustomerId和CustomerDomain.CustomerId。确保可以比较这些类型类型是否相等。

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

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

Answer 1

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

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

这取决于。在我目前工作的系统中，我们有大约15个大型服务，我们共享价值类型，如“EMailAddress”，“PhoneNumber”，“Money”等。这些类型定义明确，我们没有共享问题，但我不会因为可能在其他地方使用而分享内容，而是将实际使用的共享价值类型细化。分享时，您需要支付全系统耦合的费用。

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

不，我不会像其他人所指出的那样，客户是在订单域工作的人会知道并需要来自的数据。如果您声称“客户”和“订单”代表两个不同的域，而不是我假设“客户”域名就像CRM数据？如果您将“客户”和“订单”分别建模为“客户” - 域名不能包含您在“订单”域中所需的数据，请举例说明帐单地址。我理解您对紧密耦合和巨大对象图的反对意见，但您可以通过确保在系统中允许多个“客户”实体来处理此问题;每个“客户”代表有限上下文中自己的一组数据和行为。例如，您可以在CRM域中拥有Customer实体，在“Order”域中拥有Customer实体（我猜它实际上是一个Ordering-domain，因为“Order”听起来像一个实体而不是一个封装的业务集流程）。在您的CRM域中，客户可能拥有诸如电话号码，联系人，邮政地址等内容，在“订单” - 您的客户肯定会有订单，以及账单地址等内容。总而言之。 ：不要创建一个客户 - 拥有它，将它放在自己的域中并删除与订单的关系，你只是减小了对象图的大小。