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