DDD架构中应用层执行查询时如何引用DbContext？

核心假设 #

• 领域模型（Domain models）与持久化实体（persistence entities）相互独立
• 仓储模式（Repository Pattern）仅适用于**命令（写操作）**场景，用于完整加载聚合根
• 查询（读操作）场景下，给EF Core套仓储模式这类抽象收益极低，甚至反直觉

当前架构现状 #

• Core层：存放领域模型
• Infrastructure层：存放持久化实体
• Application层：通过DTO完成持久化实体、领域模型与表现层的对象映射

遇到的问题 #

在Application层的查询逻辑中直接使用DbContext会导致依赖Infrastructure层，但Infrastructure层又因认证、日志、对象存储等功能依赖Application层，形成循环依赖。同时无法在Application层定义IAppDbContext接口，因为该层不了解Infrastructure层的持久化实体。

已想到的方案 #

• 为每个查询在Application层定义服务接口，在Infrastructure层实现，但操作过于繁琐
• 将Infrastructure层拆分为基础设施层与持久化层，让Application层依赖持久化层解决循环依赖，但感觉只是权宜之计

业界常用解决方案 #

1. CQRS模式分离读写 #

这是最贴合核心假设的方案：

• 命令侧：沿用仓储模式，通过Core层的领域模型处理写操作，Application层调用定义在Core层的仓储接口，实现放在Infrastructure层，避免直接依赖DbContext
• 查询侧：单独在Application层定义查询服务接口，对应的实现放在新的查询基础设施模块（或Infrastructure层内拆分的查询子模块），该模块仅依赖Application层的DTO和EF Core的DbContext，不反向依赖Application层的其他服务。查询实现直接返回DTO，无需经过领域模型，最大化查询效率。

2. 持久化契约抽象 #

在Core层定义泛型查询契约接口，不绑定具体实体类型：

public interface IQueryExecutor
{
    Task<TResult> ExecuteQueryAsync<TResult>(IQuery<TResult> query);
}

在Application层定义具体查询对象（如GetUserByIdQuery），Infrastructure层实现IQueryExecutor，直接用DbContext执行查询并返回DTO。这样Application层仅依赖Core层的契约，Infrastructure层依赖Core和Application层的查询对象，从根源避免循环依赖。

3. 依赖倒置弱化边界（谨慎使用） #

若项目复杂度不高，可通过依赖倒置调整层间依赖：

• 在Infrastructure层定义IDbContext接口，仅暴露查询所需的DbSet或查询方法
• Application层依赖IDbContext接口而非具体的AppDbContext实现
• 最后在DI容器中注册AppDbContext为IDbContext的实现
  这种方式保留了直接使用EF Core查询的灵活性，同时避免循环依赖，但需注意防止领域模型与持久化实体耦合。

内容的提问来源于stack exchange，提问作者Tristan Charles Boniface