我刚刚开始学习域驱动设计，而最让我困惑的一件事就是如何确定哪一个应该是实体，哪一个应该是值对象
我知道要确定实体/值对象，我们需要基于域上下文，在一个上下文中，一个域对象可以是实体，另一个，它可以是值对象，但仍然有一些情况我可以'决定
.e.g。地址 - 在客户管理应用程序的上下文中（我们只说一个管理客户的应用程序，添加/删除/更改客户的状态等），地址显然是价值对象，因为在这里我们不需要区分一个地址与另一个地址，2个客户可以拥有相同的地址 - 另一方面，在在线预订申请的背景下，我可以说地址是一个实体吗？因为现在我们需要通过他们的账单地址来区分客户（暂时忽略案例2客户目前具有相同的地址）
对我而言，地址本身就是独一无二的，所以它绝对具有身份。因此，域对象的身份不会决定它是实体还是价值对象，如果是，那么选择的关键因素是什么？
另一个例子，我有一个应用程序列出了一个国家/地区的许多区域，用户可以选择一个区域，并找到符合其搜索条件的所有餐厅。在这种情况下，区域是值对象还是实体？目前我认为它更多的是一个实体，但仍然不是很确定。每个区域也都是独一无二的
我不确定我的问题是否清楚，我现在尽力解释我的想法
答案 0 :(得分：6)
我认为你的一些困难可能是某些术语的微妙含义。例如，你提到“对我而言，地址本身是独一无二的，所以它绝对具有身份”。就大多数人在域驱动设计中使用“身份”的方式而言，您的陈述可能不正确。
值对象的属性集是的定义。如果你改变它的任何方面，你有一个完全不同的对象。使用您的地址示例，如果您更改它的任何部分，您将获得完全不同的地址。 不相同的地址，其中的方面发生了变化。您的客户搬到了新地址;他们没有改变同一地址的各个方面。
但是，如果您是地图应用程序且地址本身已更改，则此处地址将是实体。在这种情况下，城市规划者可能想要重新编号街道上的房屋。在这种情况下，正在修改SAME地址。在这种情况下，我们需要更新实体，而不是值对象。
关于您的帐单邮寄地址示例，帐单邮寄地址可能仍然是一个价值实体（至少是它的物理地址部分）。支付方法（例如信用卡）可以是该示例中的实体，并且它可以包括其他价值对象（例如账单地址，信用卡号等）。
您可能会发现查看此问题及其答案也很有帮助：Value vs Entity objects (Domain Driven Design)
希望这会有所帮助。祝你好运！