DDD中创建未存储在数据库的聚合应采用什么设计模式？

Repository模式依然是当前场景下的最优选择，完全适配你的需求：

• Repository的核心定位是领域层访问聚合根的统一抽象入口，和底层存储介质没有绑定关系。不管聚合是通过数据库CRUD、第三方API调用还是其他方式生成/读写，都可以用Repository做统一抽象，刚好契合你对Conversation作为通用抽象层的定位，未来扩展其他会话类型时也不需要修改上层调用逻辑。
• 不推荐直接将IConversationAPIAdapter注入Command Handler，这个方案会带来两个明显的架构隐患：一是后续Conversation如果扩展多实现（比如新增音视频会议、网页在线会话等类型），Command Handler会依赖大量不同的适配器实现，逻辑会快速臃肿；二是Conversation的领域校验规则没法统一收口，很容易散落在不同的Handler中，违反单一职责原则。

落地建议 #

• 在领域层定义ConversationRepository抽象接口，仅对外暴露save、getById等业务需要的聚合操作方法，完全不涉及第三方API的相关细节
• 在基础设施层实现该ConversationRepository接口，实现类内部依赖IConversationAPIAdapter，把第三方API调用、参数转换、异常兜底等逻辑全部封装在实现层，对上层完全屏蔽实现细节
• Command Handler仅依赖ConversationRepository的抽象接口调用即可，不需要感知底层是调用API还是读写数据库，后续调整会话实现逻辑时也不需要修改Handler层代码

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