最近，我在设计一个特定的域模型时考虑了一些问题，比如Address，它可以在给定的上下文中编辑，但在另一个上下文中不可编辑。我目前的想法是，我会同时拥有地址的Value Object版本和地址的Entity，可能会附加到类似客户帐户的东西上，以获得其身份。
现在我意识到，如果我正在创建一个新的地址，比如当用户输入一个地址时，我很可能还需要能够继续编辑该地址，也许还需要在同一个有界上下文中编辑任何预先存在的地址。出于这个原因，我可以假设在这个上下文中，Address应该被建模为Entity，而不是Value Object。这就引出了我的主要问题，即如果在修改现有数据集或创建新数据时始终使用实体，那么拥有一个用于创建任何值对象的工厂是否有意义？
当我遵循这条思路时，我开始想到的规则是，值对象只应该被创建来表示对应用程序来说是静态的东西，或者已经持久化到数据库中的东西，而不是在当前域上下文中是瞬态的东西。因此，我唯一应该创建任何类型的值对象的地方是，当它们在持久值的聚合根存储库内或代表聚合根存储库内或在静态值的情况下在服务内重新水合/物化时。我开始觉得这很清楚，但我担心的是，我还没有读过其他任何地方有人得出同样的结论。无论哪种方式，我都希望有人能证实我的结论，或者让我澄清。
可以在给定上下文中编辑，但在另一个
不同上下文中实体的可变性设置的差异也可以在应用层中表示。这是一个操作问题，可能涉及身份验证和授权，应用程序服务是该逻辑的方便位置。VO和实体之间的区别并不能直接解决这些问题。仅仅因为VO应该是不可变的，并不意味着实体不能更改其引用的VO的值。例如，用户可以引用不可变的地址值，但是编辑操作可以更新用户以引用新值。允许用户在一个上下文中编辑地址而不在另一上下文中编辑可以表示为与相应上下文相关联的权限值。
这就引出了我的主要问题，那就是如果你总是在修改现有数据集或创建那么，有一个工厂来创建新数据有意义吗任何Value对象？
拥有一个用于创建VO实例的工厂当然是有意义的。这可以是VO类上的静态方法，也可以是专用对象，具体取决于您的偏好。但是，VO不应该用于解决域模型的可变性需求。相反，如上所述，这应该在应用层进行处理。