DDD:帮助我进一步了解价值对象和实体

use*_*038 6 domain-driven-design

有几个问题,阅读它们并没有帮助我.在Eric Evans DDD中,他使用地址在某些情况下作为值类型的示例.对于邮购公司而言,地址是一种值类型,因为如果地址是共享的,并且其他人住在地址,只是包裹到达地址并不重要.

这对我来说很有意义,直到我开始考虑如何设计它.鉴于第99页的图表,他有这样的:

+------------+
|Customer    |
+------------+
|customerId  |
|name        |
|street      |
|city        |
|state       |
+------------+
Run Code Online (Sandbox Code Playgroud)

这变为:

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

+------------+
|Address     | (value object)
+------------+
|street      |
|city        |
|state       |
+------------+
Run Code Online (Sandbox Code Playgroud)

如果这些是表格,地址将拥有自己的ID,以便与客户建立关系,将其转变为实体.

的理念是在关系数据库中,这些将留在同一个表,如在第一个例子,那你会使用ORM抽象地址作为值对象的功能(如NHibernate的组件功能)?

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

kam*_*mal 8

当Eric Evans谈到"实体有身份,Value Objects没有"时,他并不是在谈论数据库中的ID列 - 他在谈论身份作为一个概念.

VO没有概念身份.这并不意味着他们不应该有持久性身份.不要让持久性实施让您了解实体与VO.

您可以为Customer创建单独的表,也可以在Customer中的同一个表中创建


que*_*rin 2

在关系数据库中,这些内容将保留在同一个表中(例如第一个示例中),并且您将使用 ORM 的功能将地址抽象为值对象(例如 nHibernate 的组件功能),这一想法是否是这样的?

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

或者(如果您的 ORM 不直接支持值对象),您可以让 VO 表具有 ID,但将其隐藏在域模型中。