DDD模式下跨多数据源的User实体填充方案咨询（.NET Core场景）

跨数据源实体填充的通用业界规范 #

针对这种单领域实体属性分散在多个只读/可写数据源的场景，业界通用的实现是防腐层+仓库封装模式：由Repository层屏蔽底层多数据源的差异，上层业务仅需和完整的领域实体交互，无需关心属性的实际来源。你当前不需要修改Microsoft Graph数据的场景刚好匹配这个模式的最佳适用范围。

方案选型推荐 #

在预算有限、交付时间紧张的前提下，优先选择方案1，三个方案的对比逻辑如下：

• 方案3首先排除：将数据拼接逻辑抛给API调用方属于典型的职责外漏，相当于把领域层的核心逻辑散到了外部依赖中，后续只要调整用户属性逻辑，所有调用方都要同步修改，后期维护成本极高，完全得不偿失。
• 方案2属于过度设计：该方案的优势是领域层和数据源完全解耦，但这个优势只有在需要频繁切换数据源、或者多数据源写入的场景下才能体现。你当前没有修改Graph数据的需求，也没有数据源切换的规划，额外做双向映射只会增加无意义的工作量，拖慢交付节奏。
• 方案1做少量优化即可满足需求，开发成本最低：
  • 保留你原本的设计：领域User实体包含所有业务需要的属性，EFCore数据模型和自有库表结构一一对应
  • 把调用Microsoft Graph补全属性的逻辑封装在UserRepository内部，上层业务调用Repository的查询方法时，直接拿到的就是完整的User实体，完全感知不到底层多数据源的差异，符合DDD的设计原则
  • 可选优化：用ASP.NET Core自带的IMemoryCache给Graph返回的用户属性做几分钟到几小时的缓存，避免频繁调用Graph接口拖慢响应速度，实现成本极低

后续演进建议 #

如果后续项目迭代出现了身份提供商切换、多数据源写入等需求，再将方案1演进为方案2即可，前期不需要为了不存在的需求提前投入开发成本。

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