DDD中Repository与Factory辨析：外部数据转换是重水化还是新建对象？

该场景下Factory的工作本质是带上下文规则补全的跨数据源重水化，不属于全新对象构建：

• 实体ID沿用外部系统的唯一业务标识，对应领域实体在业务维度已经存在，并非当前限界上下文内新生成的业务对象
• 核心逻辑是将异构存储形态的实体数据，还原为当前上下文可识别的领域对象，只是相比从自有存储重水化多了必填属性补全、关联关系校验的步骤

你当前的流程问题出在将带领域依赖的构建逻辑放在了应用层的Factory中，Factory本身的核心职责是无状态的纯对象构造，不应该依赖Repository等外部组件加载关联数据，调整后各层职责如下：

• 基础设施层（防腐层/ACL）：外部SQL Server适配器的职责保持不变，仅负责查询外部数据源、做原始数据到应用层DTO的映射，完全屏蔽外部存储的异构特性，不承载任何领域逻辑
• 应用层：仅做流程编排，不承载领域规则：调用外部适配器获取DTO、调用领域层的导入服务生成合法领域对象、调用自有Repository完成持久化
• 领域层：新增专门的外部实体导入领域服务，承载所有转换规则：依赖关联聚合的Repository加载关联数据、补全导航ID与必填附加属性、校验所有业务规则合法性，最终输出符合当前上下文要求的完整领域对象，原来的Factory仅保留无依赖的纯字段构造逻辑供该领域服务调用
• 自有SQL Server对应的Repository：仅负责当前上下文内的领域对象持久化、自有存储的重水化逻辑，不涉及任何外部数据转换规则

额外实践建议 #

如果是定期批量迁移场景，可以将整个迁移流程封装为独立的后台作业服务，和常规在线业务服务解耦，避免批量操作影响线上业务稳定性。适配器层的Automapper映射仅用于外部原始数据到DTO的转换，领域层内的对象赋值建议显式编写，避免AutoMapper的隐式转换漏掉业务规则校验。

内容的提问来源于stack exchange，提问作者Joshua0414