Domain driven design 在遵循DDD实践时，有价值对象工厂有意义吗？

最近，当我试图设计一个特定的域模型时，我考虑了一些过去遇到的问题，比如地址，它可以在给定的上下文中编辑，但在另一个上下文中不可编辑。我目前的想法是，我会将地址的值对象版本和地址的实体（可能会附加到客户帐户之类的东西上）结合起来，以获得其身份

现在我意识到，如果我要创建一个新地址，比如当用户输入一个地址时，我很可能还需要能够继续编辑该地址，也许还需要在相同的有界上下文中编辑任何先前存在的地址。出于这个原因，我可以假设在这个上下文中，地址应该建模为实体，而不是值对象。这就引出了我的主要问题，即如果在修改现有数据集或创建新数据时始终使用实体，那么创建任何值对象的工厂有意义吗

当我遵循这一思路时，开始出现的规则是，创建值对象时，应该只表示对应用程序来说是静态的或已经持久化到数据库中的对象，而不是当前域上下文中暂时的对象。因此，对于任何类型的值对象的创建，我唯一应该做的就是在聚合根存储库中或代表聚合根存储库对它们进行重新水合/物化，以获得持久值，或者在静态值的情况下在服务中进行重新水合/物化。这对我来说似乎已经很清楚了，但我担心的是，我还没有读到其他任何地方有人得出同样的结论。不管怎样，我希望有人能证实我的结论，或者让我直截了当

可在给定上下文中编辑，但在给定上下文中不可编辑的 另一个

不同上下文中实体的可变性设置差异也可以在应用层中表示。这是一个操作问题，可能涉及身份验证和授权，应用程序服务是该逻辑的一个方便位置。VO和实体之间的区别并不能直接解决这些问题。仅仅因为VO应该是不可变的，并不意味着实体不能更改它引用的VO的值。例如，用户可以引用不可变的地址值，但是编辑操作可以更新用户以引用新值。允许用户在一个上下文中而不是在另一个上下文中编辑地址可以表示为与相应上下文关联的权限值

这就引出了我的主要问题，那就是如果你总是 在修改现有数据集或创建 那么，有一个工厂来创建新数据有意义吗 有价值的东西吗

---

有一个工厂来创建VO实例当然是有意义的。这可以是VO类上的静态方法，也可以是专用对象，具体取决于您的偏好。然而，不应使用VO来解决域模型的可变性需求。相反，如上所述，这应该在应用层处理。

“编辑操作可以更新用户以引用新值”。这个建议正好触及我问题的核心。我以前也有同样的假设，但最近我开始怀疑这一点，并怀疑拥有值对象的价值之一是否永远不必猜测它们是否需要自己持久化。换句话说，实体会被修改，修改的一种方式是当它们对对象的引用发生变化时。对于实体，可能需要创建/修改该实体。一个值对象引用可以严格地暗示关系的变化。我想我说的是关系的变化这一事实很明显，我说的是只读实体，或者一些人认为是快照而不是值对象。谢谢你帮我澄清！在我接受你的回答之前，我会把这个问题留一点时间，让其他人有机会插话。也许你在考虑类似活动采购的事情？在这种情况下，只读值对象显示为显式表示实体上状态更改的事件。我知道事件源，但我还没有使用该模型。我的想法主要是，在创建新的值或一组通常被建模为ValueObject的值时，将案例建模为实体以进行修改是否总是有意义的。我明白了，但在我看来，这方面的决定可能会极大地影响到如何进行变更检测。