在遵循 DDD 实践时，拥有一个值对象工厂是否有意义？

Question

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

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

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

Answer 1

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

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

这让我想到了我的主要问题，即如果你应该总是 在修改现有数据集或创建数据集时使用实体 那么，拥有一个工厂来创建新数据是否有意义 任何值对象？

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