首页 > 解决方案 > 在确定某事物是实体还是值对象时,是否应该忽略唯一性?

问题描述

唯一性是否被认为是 DDD 中的持久性问题?

我问的原因是因为我Customer在订单引用上下文中有一个对象。例如,订单是给客户的,客户必须支付一定的费用。

从技术上讲,我不会允许客户拥有与另一个客户相同的代码或名称。这意味着如果我有两个Customer具有相同代码和名称的对象,它们将始终像值对象一样被对待。

但本能地,aCustomer感觉就像一个实体。是唯一约束让我失望,还是我认为它是一个价值对象是正确的?

订单报价上下文还将允许从管理页面添加/编辑/删除客户。混乱可能是由此引起的吗?管理页面是否应该是另一个上下文的一部分,其中Customer有一个实体,并且订单引用上下文将Customer用作值对象?

标签: entitydomain-driven-designaggregaterootvalue-objects

解决方案


这是一个很好的问题,您已经部分回答了它,您的客户是您有限的管理上下文中的实体。

判断一个对象是否是一个实体的一个好的经验法则是用身份的概念来思考。如果您的对象需要一个与时间流逝保持不变的身份,即使该人的姓名或联系方式可以更改,那么它也可能是一个实体。

但是,定义了该概念后,您可以拥有一个 CustomerId,从业务角度来看,它由不变量组成,在您的情况下是代码和名称。

此 CustomerId 不是技术 ID,它是业务 ID,您的实体的身份将是此 ID。在 Order 引用有界上下文中,您可以使用相同的对象引用您的 Customer(可能在共享上下文中的某处定义,或者通过复制代码:在 DDD 中可以复制一些代码以促进松散耦合)。


推荐阅读