域驱动设计 – DDD：帮助我进一步理解价值对象和实体

发布时间：2020-12-13 20:25:56 所属栏目：百科来源：网络整理

导读：有几个问题,阅读它们并没有帮助我.在Eric Evans DDD中,他使用地址在某些情况下作为值类型的示例.对于邮购公司而言,地址是一种值类型,因为如果地址是共享的,并且其他人住在地址,只是包裹到达地址并不重要. 这对我来说很有意义,直到我开始考虑如何设计它.鉴于

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

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

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

这变为：

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

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

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

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

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

Is the idea that in a relational
database these would stay in the same
table,such as in the first example,
and that you’d use features of the ORM
to abstract address as a value object
(such as nHibernate’s component
features)?

是的,一般来说,这就是主意.

或者(如果您的ORM不直接支持Value Objects),您可以让VO表具有ID,但在您的域模型中隐藏它.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!