多次使用的值对象是实体吗？
Is a Value Object that is used many times an entity?
题中的问题可能不是很清楚，我来解释一下：
在我的模型中，我有一个人，它有一个地址。但是，许多人可以共享同一个地址。
当我定义我的模型时，我假设 Person 是一个实体，但是 Address 是一个值对象，因为如果您更改地址的单个 属性，那么它就不再是同一个地址了。
由于多个人可以共享一个地址，如果我直接进入数据库实现，并天真地假设这个人有一些 address_xxxx 字段，它不会在数据库中生成太多重复项吗？ person 有一个与地址 table 相关的 address_id 字段不是更好吗？如果是这样，那么地址是实体吗？
Is a Value Object that is used many times an entity?
不，但这取决于...
通常情况下，值对象实际上是实体的代理标识符，您可能没有在模型中明确意识到这一点。
例如：
1600 Pennsylvania Ave NW
Washington, DC
20500
如果你仔细看，你会看到嵌入其中
- 一条街道的名称
- 城市名称
如果这些是对模型中 street/city 实体 的引用，则 "address" 表示某个实体的当前状态（例如： "The White House").
使事情进一步复杂化 - 您需要为您的模型提供合适的抽象。
考虑金钱：
{USD:100}
这是一个值类型，我们可以用 "different" USD:100
替换任何 USD:100
{USD:100, SerialNumber:KB46279860I}
这仍然是一个值（它的状态），但它是流通中（某处）存在的特定票据的状态。我们这里有一个 信息资源 ，它描述了现实世界中某个地方的实体。
您还需要注意重合属性。例如;街道名称发生变化——address 的值应该改变吗？如果模型关心位置的当前标识符，那么它也许应该关心。如果模型正在跟踪您两个月前放在信封上的信息，那么它肯定不应该。 （换句话说，当我们更改街道实体的标签时，已经打印在信封实体上的标签并没有改变）。
这是一个重要的问题，但答案会根据您当时建模的内容而有所不同。
In my model, I have an Person, that has an Address. However, many
Persons can share the same Address.
Isn't it better that person has an address_id field, related to an
address table ? If so, then Address is an Entity right?
您必须认识到有两种截然不同的模型，域模型和持久性模型，并且两者可能不同意概念是实体还是值。
您要做的第一件事是问问自己，从域的角度来看什么是地址？您的域是否对地址的生命周期感兴趣，或者它们只是不可变的值？例如，如果地址中有拼写错误会怎样？您是简单地丢弃不正确的地址并替换它，还是宁愿修改原始地址详细信息以跟踪其连续性？这些问题将帮助您从域的角度确定地址是实体还是值。
现在，一个概念在域中可能是一个值，而在持久性模型中是一个实体。例如，假设您对域中地址的生命周期不感兴趣，但您非常关心优化存储 space。在这种情况下，您可以为数据库中的唯一地址提供标识符并将其用于关系，而不是多次复制相同的地址详细信息。
但是，这样做会在您的模型之间引入额外的紧张关系，因此您必须确保这样做确实有好处。
题中的问题可能不是很清楚，我来解释一下：
在我的模型中，我有一个人，它有一个地址。但是，许多人可以共享同一个地址。
当我定义我的模型时，我假设 Person 是一个实体，但是 Address 是一个值对象，因为如果您更改地址的单个 属性，那么它就不再是同一个地址了。
由于多个人可以共享一个地址，如果我直接进入数据库实现，并天真地假设这个人有一些 address_xxxx 字段，它不会在数据库中生成太多重复项吗？ person 有一个与地址 table 相关的 address_id 字段不是更好吗？如果是这样，那么地址是实体吗？
Is a Value Object that is used many times an entity?
不，但这取决于...
通常情况下，值对象实际上是实体的代理标识符，您可能没有在模型中明确意识到这一点。
例如：
1600 Pennsylvania Ave NW
Washington, DC
20500
如果你仔细看，你会看到嵌入其中
- 一条街道的名称
- 城市名称
如果这些是对模型中 street/city 实体 的引用，则 "address" 表示某个实体的当前状态（例如： "The White House").
使事情进一步复杂化 - 您需要为您的模型提供合适的抽象。
考虑金钱：
{USD:100}
这是一个值类型，我们可以用 "different" USD:100
替换任何 USD:100{USD:100, SerialNumber:KB46279860I}
这仍然是一个值（它的状态），但它是流通中（某处）存在的特定票据的状态。我们这里有一个 信息资源 ，它描述了现实世界中某个地方的实体。
您还需要注意重合属性。例如;街道名称发生变化——address 的值应该改变吗？如果模型关心位置的当前标识符，那么它也许应该关心。如果模型正在跟踪您两个月前放在信封上的信息，那么它肯定不应该。 （换句话说，当我们更改街道实体的标签时，已经打印在信封实体上的标签并没有改变）。
这是一个重要的问题，但答案会根据您当时建模的内容而有所不同。
In my model, I have an Person, that has an Address. However, many Persons can share the same Address.
Isn't it better that person has an address_id field, related to an address table ? If so, then Address is an Entity right?
您必须认识到有两种截然不同的模型，域模型和持久性模型，并且两者可能不同意概念是实体还是值。
您要做的第一件事是问问自己，从域的角度来看什么是地址？您的域是否对地址的生命周期感兴趣，或者它们只是不可变的值？例如，如果地址中有拼写错误会怎样？您是简单地丢弃不正确的地址并替换它，还是宁愿修改原始地址详细信息以跟踪其连续性？这些问题将帮助您从域的角度确定地址是实体还是值。
现在，一个概念在域中可能是一个值，而在持久性模型中是一个实体。例如，假设您对域中地址的生命周期不感兴趣，但您非常关心优化存储 space。在这种情况下，您可以为数据库中的唯一地址提供标识符并将其用于关系，而不是多次复制相同的地址详细信息。
但是，这样做会在您的模型之间引入额外的紧张关系，因此您必须确保这样做确实有好处。