有几个问题,阅读它们并没有帮助我.在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,但在您的域模型中隐藏它.
