DDD：帮助我进一步了解值对象和实体答案

【问题标题】：DDD: Help me further understand Value Objects and EntitiesDDD：帮助我进一步了解值对象和实体
【发布时间】：2011-02-15 21:22:00
【问题描述】：

对此有几个问题，阅读它们对我没有帮助。在 Eric Evans DDD 中，他使用了在某些情况下地址作为值类型的示例。对于邮购公司来说，地址是一个值类型，因为地址是否被共享，还有谁住在这个地址并不重要，只是包裹到达了这个地址。

这对我来说很有意义，直到我开始考虑如何设计它。鉴于第 99 页上的图表，他是这样的：

+------------+
|Customer    |
+------------+
|customerId  |
|name        |
|street      |
|city        |
|state       |
+------------+

这会变成：

+------------+
|Customer    | (entity)
+------------+
|customerId  |
|name        |
|address     |
+------------+

+------------+
|Address     | (value object)
+------------+
|street      |
|city        |
|state       |
+------------+

如果这些是表，Address 将拥有自己的 Id，以便与客户建立关系，将其转变为实体。

在关系数据库中，这些将保留在同一个表中的想法，例如在第一个示例中，并且您将使用 ORM 的功能将地址抽象为值对象（例如 nHibernate 的组件功能） ?

我意识到几页后他谈到了非规范化，我只是想确保我正确理解了这个概念。

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

当 Eric Evans 谈到“实体有身份，值对象没有”时，他不是在谈论数据库中的 ID 列 - 他是在谈论身份作为一个概念。

VO 没有概念上的身份。这并不意味着他们不应该有持久性身份。不要让持久性实现影响您对实体与 VO 的理解。

您可以为地址创建单独的表或在客户的同一表中创建单独的表

【讨论】：

感谢您的解释，这让我对在这种情况下使用 DDD 更有信心。

【解决方案2】：

是在关系中的想法数据库这些将保持不变表，例如在第一个示例中，并且你会使用 ORM 的特性将地址抽象为值对象（比如nHibernate的组件功能）？

是的，一般来说，就是这样。

或者（如果您的 ORM 不直接支持值对象），您可以让 VO 表有一个 ID，但将其隐藏在您的域模型中。

【讨论】：

【解决方案3】：

我个人并不关心在值对象上有 ID，只要它们正确地覆盖相等比较（因为值对象的不同之处在于它们的值而不是身份）。

将值对象映射到数据库是技术问题，有时（例如，将道具标记为虚拟，以便 ORM 可以在下面爬行）您只需要稍微牺牲领域模型的纯度即可。或者让您的基础架构更智能 - 使用 nhib 组件或其他东西。

【讨论】：

【解决方案4】：

是的，通常 Address 会保留在同一个表中。地址将被映射如下：

+-----------------+
|Customer         |
+-----------------+
|customerId       |
|name             |
|address_street   |
|address_city     |
|address_state    |
+-----------------+

如果地址是一个实体，那么它会在一个单独的表中，如你所说。如果两个相同的客户链接到相同的地址实体，则更改该地址的属性将影响两个客户。但是，VO 实现只会影响其中之一。

【讨论】：