DDD:对实体/值对象进行分类

Phu*_*yen 2 dns entity domain-driven-design object

我刚开始学习域驱动设计,而最让我困惑的几件事之一是如何确定哪一个应该是实体,哪一个应该是值对象

我知道要确定实体/值对象,我们需要基于域上下文,在一个上下文中,一个域对象可以是实体,另一个,它可以是值对象,但仍有一些情况我无法决定

.eg地址 - 在客户管理应用程序的上下文中(我们只说一个管理客户的应用程序,添加/删除/更改客户的状态等),地址显然是值对象,因为这里我们不需要区分一个来自另一个地址,2个客户可以拥有相同的地址 - 另一方面,在在线预订应用程序的上下文中,我可以说地址是一个实体吗?因为现在我们需要通过他们的账单地址来区分客户(只是忽略案例2目前具有相同地址的客户)

对我而言,地址本身就是独一无二的,所以它绝对具有同一性.因此,域对象的身份不会决定它是实体还是价值对象,如果是,那么选择的关键因素是什么?

另一个例子,我有一个应用程序列出了一个国家/地区的许多区域,用户可以选择一个区域,并找到符合其搜索条件的所有餐厅.在这种情况下,区域是值对象还是实体?目前我认为它更多的是一个实体,但仍然不是很确定.每个区域也是独一无二的

我不确定我的问题是否清楚,我现在尽力解释我的想法

Chr*_*inn 6

我认为你的一些困难可能是某些术语的微妙含义.例如,你提到"对我来说,地址本身是独一无二的,所以它绝对具有身份".就大多数人在域驱动设计中使用"身份"的方式而言,您的陈述可能不正确.

值对象的属性集其定义.如果你改变它的任何方面,你有一个完全不同的对象.使用您的地址示例,如果您更改它的任何部分,您将获得完全不同的地址.它是不是用方面相同的地址的它改变.您的客户搬到了新地址; 他们没有改变同一地址的各个方面.

但是,如果您是一个映射应用程序并且地址本身已更改,那么此处的地址将是一个实体.在这种情况下,城市规划者可能想要重新编号街道上的房屋.在这种情况下,正在修改SAME地址.在这种情况下,我们需要更新实体,而不是值对象.

关于您的帐单邮寄地址示例,帐单邮寄地址可能仍然是一个价值实体(至少是它的物理地址部分).支付方法(例如信用卡)可以是该示例中的实体,并且它可以包括其他价值对象(诸如账单地址,信用卡号等).

您可能会发现查看此问题及其答案也很有帮助: 值与实体对象(域驱动设计)

希望这可以帮助.祝好运!

  • 非常感谢,你的解释是我正在寻找的,现在一切都更清楚了 (2认同)