在域之间共享值对象是个好主意吗？
假设系统中有两个域：Orderdomain 和 Customerdomain。
这两个域都相当复杂且庞大，因此将它们合并到一个域中并不是一种选择。
但他们之间存在业务关系。在每个订单上，客户充当订购者。
我脑子里至少有三个解决方案。
将 customerId 作为原始类型存储在 Order 和 Customer 上。
创建两个值对象 OrderDomain.CustomerId 和 CustomerDomain.CustomerId。确保可以比较这些类型的相等性。
使用 valeobject CustomerId 创建第三个组件“SharedValueObjects”，并在两个域中使用该类型
您首选哪一个？想出第四个更好的吗？
Let´s assume we´ve got two domains in a system: Orderdomain and Customerdomain.
Both domains are rather complex and big so merge them into one domain is not an option.
But there is a business relationship between them. On each Order a Customer acts as a Orderer.
I have at least three solutions in my mind.
Store the customerId as a primitive type on both Order and Customer.
Make two valueobjects OrderDomain.CustomerId and CustomerDomain.CustomerId. Make sure these type types can be compared for equality.
Make a third component "SharedValueObjects" with a valeobject CustomerId and use that type in both Domains
Which one is preferred or can you come up with a forth better one?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将尝试回答您关于价值对象的一般问题以及您的评论中更具体的问题？
这取决于。在我目前工作的系统中，我们有 15 个左右的大型服务，我们共享“EMailAddress”、“PhoneNumber”、“Money”等值类型。这些类型定义明确，我们没有共享问题，但我不会仅仅因为它们可能在其他地方使用而共享东西，请让实际使用的人体会到您共享的价值类型。共享时，您要付出系统范围耦合的代价。
不，我不会，正如其他人指出的那样，客户是在订单域工作的人会了解并需要从中获取数据的东西。如果您声称“客户”和“订单”代表两个不同的域，那么我假设“客户”域类似于 CRM 数据？如果您分别对“客户”和“订单”进行建模，则“客户”域不能包含“订单”域中所需的数据，例如账单地址。我理解您反对紧密耦合和巨大的对象图，但是您可以通过确保系统中允许多个“客户”实体来处理这个问题；每个“客户”在有限的上下文中代表自己的一组数据和行为。例如，您可以在 CRM 域中同时拥有一个客户实体，在“订单”域中也可以拥有一个客户实体（我猜它实际上是一个订购域，因为“订单”听起来像是一个实体，而不是一组封装的业务）过程）。在您的 CRM 域中，客户可能有电话号码、联系人、邮政地址等信息，在“订单”域中，您的客户肯定会有订单以及帐单地址等信息。总结一下：不要创建一个拥有一切的客户，将其放在自己的域中并删除与订单的关系，您只是减小了对象图的大小。
I'll try to answer both your general question about value objects and the more specific one from your comments?
It depends. In the system I currently work on we have 15 or so large scale services, we share value types like "EMailAddress", "PhoneNumber", "Money", etc. These types are well-defined and we have no sharing issues, but I wouldn't share stuff just because they might be used somewhere else, savour your shared value-types to the ones who are actually used. When sharing you pay the price of system-wide coupling.
No I would not, as others has pointed out, Customer is something that someone who is working in the order-domain would know about and require data from. If you claim that "Customer" and "Order" represents two different domains than I am assuming that the "Customer"-domain is something like CRM-data? If you are modelling "Customer" and "Order" separately than the "Customer"-domain can not contain the data which you require in your "Order"-domain, lets say for example a billing address. I understand your objection against tight coupling and huge object graphs, but you can handle this by making sure that you allow multiple "Customer"-entities in your system; each "Customer" representing its own set of data and behaviour within a bounded contex. For example, you can have both a Customer entity in your CRM-domain and a Customer entity in your "Order"-domain (I guessing its really a Ordering-domain, because "Order" sounds like an entity not an encapsulated set of business processes). In your CRM-domain the customer might have stuff like, phone numbers, contact persons, postal addresses, etc), in the "Order"-domain your customer will certainly have orders, and stuff like a billing address, etc. So to summarize: don't create a customer-which-has-everyting, put that in its own domain and remove the relationship to orders, you are only reducing the size of your object graph.