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的组件功能)?
我意识到几页后他谈到非规范化,我只是想确保我正确地理解这个概念.
当Eric Evans谈到"实体有身份,Value Objects没有"时,他并不是在谈论数据库中的ID列 - 他在谈论身份作为一个概念.
VO没有概念身份.这并不意味着他们不应该有持久性身份.不要让持久性实施让您了解实体与VO.
您可以为Customer创建单独的表,也可以在Customer中的同一个表中创建
在关系数据库中,这些内容将保留在同一个表中(例如第一个示例中),并且您将使用 ORM 的功能将地址抽象为值对象(例如 nHibernate 的组件功能),这一想法是否是这样的?
是的,一般来说,就是这个想法。
或者(如果您的 ORM 不直接支持值对象),您可以让 VO 表具有 ID,但将其隐藏在域模型中。