Domain driven design DDD：帮助我进一步了解价值对象和实体

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

这对我来说很有意义，直到我开始思考如何设计它。根据第99页的图表，他是这样写的：

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

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

这将更改为：

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

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

如果这些是表，地址将有自己的Id，以便与客户建立关系，将其变成一个实体

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

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

这是一个关系型的概念吗 这些数据库将保持不变 表，例如在第一个示例中， 你会使用ORM的功能 将地址抽象为值对象 （如nHibernate的组件） 特征）

是的，一般来说，这是一个想法

---

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

我个人不在乎在值对象上有ID，只要它们正确地覆盖了相等比较（因为值对象不同于它们的值而不是标识）

---

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

当Eric Evans谈到“实体有身份，价值对象没有身份”时，他所说的不是数据库中的ID列—他所说的身份是一个概念

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

---

您可以为地址创建单独的表，也可以在Customer的同一个表中创建。是的，通常地址将保留在同一个表中。地址映射如下：

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

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

---

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

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