我将尝试回答您关于价值对象的一般问题以及您评论中更具体的问题?
- 域可以共享值对象吗?
这取决于。在我目前工作的系统中,我们有 15 个左右的大型服务,我们共享值类型,如“EMailAddress”、“PhoneNumber”、“Money”等。这些类型定义明确,我们没有共享问题,但我不会仅仅因为它们可能会在其他地方使用而共享东西,而是将您共享的值类型与实际使用的类型共享。共享时,您付出了系统范围耦合的代价。
- 我会将客户与订单之间的关系公开为包装密钥的值对象吗?
不,我不会,正如其他人指出的那样,客户是在订单领域工作的人会知道并需要数据的东西。如果您声称“客户”和“订单”代表两个不同的域,而不是我假设“客户”域类似于 CRM 数据?如果您将“客户”和“订单”分别建模而不是“客户”域不能包含您在“订单”域中需要的数据,例如账单地址。我理解您反对紧密耦合和庞大的对象图,但您可以通过确保在您的系统中允许多个“客户”实体来处理这个问题;每个“客户”在有界上下文中代表自己的一组数据和行为。例如,您可以在您的 CRM 域中拥有一个客户实体,在您的“订单”域中拥有一个客户实体(我猜它实际上是一个订单域,因为“订单”听起来像是一个实体,而不是一组封装的业务流程)。在您的 CRM 域中,客户可能有电话号码、联系人、邮政地址等内容,在“订单”域中,您的客户肯定会有订单以及账单地址等内容。所以总结一下:不要创建一个拥有一切的客户,将其放在自己的域中并删除与订单的关系,您只是在减小对象图的大小。听起来像是一个实体,而不是一组封装的业务流程)。在您的 CRM 域中,客户可能有电话号码、联系人、邮政地址等内容,在“订单”域中,您的客户肯定会有订单以及账单地址等内容。所以总结一下:不要创建一个拥有一切的客户,将其放在自己的域中并删除与订单的关系,您只是在减小对象图的大小。听起来像是一个实体,而不是一组封装的业务流程)。在您的 CRM 域中,客户可能有电话号码、联系人、邮政地址等内容,在“订单”域中,您的客户肯定会有订单以及账单地址等内容。所以总结一下:不要创建一个拥有一切的客户,将其放在自己的域中并删除与订单的关系,您只是在减小对象图的大小。