当实现新的聚合根实例时，这些实例是从不同的有界上下文中的实体持久化的数据构建的，当在不可逆状态之间转换时，更好的域驱动设计是否应该由此负责存储库或工厂。
家装承包商示例
假设您有一个名为 Proposal 的聚合根，它代表一些家庭建设工作的提案。在单独的有界上下文中，您可以使用以下流程来复制提案中的信息，以制定新的 WorkItem 聚合根，以跟踪要完成的实际工作。
在制定新的WorkItem时，我发现至少有两种可能性来承担这个责任：
- 创建在 WorkItemRepository 上获取方法，该方法将提案ID作为参数，并根据提案中的信息制定现有的 WorkItem 。 WorkItem 可能需要具有某种类型的状态值，以指示它是否仍处于提议状态，并持久保存仍处于提案状态的任何 WorkItem 可以被持久性验证服务阻止。遵循这种方法会有点奇怪，因为在工作项的有界上下文中不需要创建新的工作项。
- 为 WorkItemFactory 创建一个接口和具体类对，公开一个方法，例如 CreateWorkItemFromProposal ，它将提议ID作为参数，基本上与存储库Get方法已经完成。此选项使用类似于存储库的典型接口/实现，其中接口是域的一部分，但具体实现被视为基础结构。从长远来看，这种方法似乎更灵活，但另一方面需要将工厂的合同和实施分开，我更常见的是存储库，而不是DDD中的服务和工厂。我的典型聚合根工厂在每次调用它们时都不会从持久性中提取任何内容，是否应该这样做？
为了上述示例，假设提案ID与后面的工作项ID保持相同的情况可能是有用的。换句话说， Proposal 和 WorkItem 是同一底层实体的不同视图，并在单独的域上下文中使用。
当然，我想也欢迎我在上面的简短列表中遗漏的不同选项，只要它们属于域驱动设计的一般惯例。