DDD：帮助我进一步理解值对象和实体

Question

关于此有几个问题，阅读它们对我没有帮助。在 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 的组件功能），这一想法是否是这样的？

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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