为什么我们需要识别实体和价值对象？

Question

在Domain Driven Design中，域对象分为两类，实体和值对象。很容易弄清楚哪个是实体，这是价值对象，但我不知道为什么要做那个？在DDD出现之前，我们在没有实体和值对象的情况下对域进行建模。在DDD被转发后，我们使用实体和值对象来对域对象进行分类，那么这种分类有什么优势呢？

Answer 1

  

域对象分为两类，

实际上，不，对象是域<​​strong>概念的可能实现，它基本上只是信息，而不是代码。概念可以是实体，因为无论其如何随时间变化，以独特且一致的方式识别它是有意义的（例如：客户可以更改其名称，但它是同一客户.2个具有相同客户的客户名字不一定是同一个人）。

一个值对象（一个仍然提醒我们DDD开始有点过于耦合OOP的名称）代表一个Domain概念，它只是一个值。或者更准确地说，企业只关心它的价值。如果你改变它，它就是另一个值。基本上，5美元是5美元，你真的不在乎哪一个，其中任何一个都足够好，因为只有值很重要。

另一件事是，作为域建模者，您根据业务对概念的看法来识别概念的本质。该公司会告诉您他们关心的事情。

现在，我们知道一个概念可以是一个实体，我们可以选择它的某个实例（具有Id 3的用户）。你不能用VO做到这一点，因为VO没有身份。

更重要的是，当我们识别聚合时，大多数情况下，聚合组件（其他概念）主要是VO，因为它们通常只是值（但它们确实尊重业务约束）。 / p>

因此，总之，我们将概念分类为实体和VO，因为

• 企业以这种方式看待它们：唯一可识别的或仅仅是价值
• 实体保持其身份，无论它们如何变化（显然身份本身是只读的），我们将每一个视为唯一
• VO是可以互换使用的值，我们不关心哪个只要它们代表相同的值（它本身，作为实现细节可以是复杂的 - 复合值）。此外，VO本质上是不可改变的，因此我们知道我们无法改变它而不会成为另一个价值。

Answer 2

  

在DDD出现之前，我们对没有实体和值对象的域建模。在DDD被转发后，我们使用实体和值对象来对域对象进行分类，那么这种分类有什么优势呢？

您应该查看Blue Book的第5章（“软件中表达的模型”）。

埃文斯写道：

  

定义明确遵循一种模式或另一种模式的对象会使对象不那么模糊，并为稳健设计的具体选择铺平道路。

     

跟踪ENTITIES的标识至关重要，但将标识附加到其他对象可能会损害系统性能，添加分析工作，并通过使所有对象看起来相同来混淆模型。

     

......两个VALUE OBJECTS之间的双向关联是没有意义的。没有身份，说一个对象指向指向它的相同VALUE OBJECT是毫无意义的。你可以说最多的是它指向一个与指向它的对象相等的对象，但你必须在某个地方强制执行该不变量。

我自己的总结是这样的：认识到某些域概念是实体是有用的，因为它鼓励设计者承认身份，连续性和生命周期是该领域中实体的重要关注点。同样地，认识到一个概念是一个价值立即使你摆脱这些担忧，将你的注意力转移到它们不可改变的本质和等同性上。