.NET 8 Clean Architecture中合规实现Repository Pattern的最佳实践

架构老林

2026-6-14

问题：Clean Architecture + DDD 下的仓储模式实现困惑

我正在开发一个遵循Clean Architecture的.NET 8项目，希望在遵循领域驱动设计原则的前提下正确实现Repository Pattern。

当前架构设置

领域层：包含实体与领域逻辑
应用层：包含用例（CQRS命令/查询）
基础设施层：实现数据库访问（EF Core）
表现层：ASP.NET Core API

面临的挑战

我常看到仓储暴露GetByIdAsync(int id)或GetAllAsync()这类方法，但了解到在Clean Architecture中，领域模型不应依赖特定持久化细节。

我的疑问

仓储应返回领域实体，还是先映射为DTO？
返回领域实体可能向基础设施层暴露内部细节，使用DTO则可能导致不必要的抽象。仓储接口应放置在何处？
- 领域层（遵循依赖倒置原则）？
- 应用层（因领域应与持久化无关）？
在Clean Architecture中，从仓储暴露IQueryable是否为良好实践？有人认为这会将EF Core实现细节泄露到应用层，也有人认为这提升了LINQ查询的灵活性。

我的拟议方案

在应用层定义仓储接口，在基础设施层使用EF Core实现仓储；在领域实体中使用领域事件而非仓储；通过MediatR + Specification Pattern由应用服务处理查询。

请问在Clean Architecture中如何构建仓储以确保可测试性与可维护性？是否有更优替代方案（如查询对象模式）？期待相关见解与最佳实践！

回答

1. 仓储应返回领域实体还是DTO？

仓储的核心职责是封装持久化细节，为领域层/应用层提供领域实体的访问入口，所以仓储应该直接返回领域实体。DTO是用于层间数据传输的对象，属于应用层或表现层范畴，不应让仓储承担映射DTO的职责——这会把数据转换逻辑耦合到持久化层，违反单一职责原则。

如果需要将实体转换为DTO，应该在应用层的服务（比如CQRS的查询处理程序）中完成，使用AutoMapper这类工具简化映射逻辑即可。

2. 仓储接口的放置位置

根据依赖倒置原则（DIP），仓储接口必须放在领域层，原因如下：

领域层是架构核心，它定义自身需要的持久化契约（仓储接口），基础设施层只是契约的实现者，这样领域层完全不依赖任何外部持久化细节。
若把接口放在应用层，领域层若需访问数据就会依赖应用层，打破Clean Architecture“内层不依赖外层”的规则（领域层是最内层，应用层在外层）。

你担心的“返回领域实体向基础设施层暴露内部细节”是多余的——基础设施层本身就是负责持久化的，它需要知道实体结构才能完成映射（比如EF Core的实体配置），这属于合理依赖，而非“泄露”。

3. 仓储是否应该暴露`IQueryable`？

不建议直接暴露IQueryable，核心原因：

IQueryable是EF Core（或其他ORM）的特定类型，会把持久化细节泄露到上层（应用层甚至领域层），导致上层代码依赖ORM实现，违反Clean Architecture的隔离原则。
暴露IQueryable会让上层随意编写查询逻辑，容易出现性能问题（比如N+1查询），也难以统一管控查询规则。

替代方案是使用Specification模式：在领域层定义规格类，封装查询条件、关联加载、排序、分页等逻辑，仓储接收规格对象并执行对应查询。这样既保留查询灵活性，又不会泄露ORM细节。

对你拟议方案的评价

「在应用层定义仓储接口」不符合DIP和Clean Architecture分层规则，建议调整为领域层定义接口，基础设施层实现。
「领域实体中使用领域事件而非仓储」是正确实践——领域实体应专注业务逻辑，通过领域事件触发后续操作，而非直接依赖仓储。
「MediatR + Specification Pattern处理查询」是非常合适的组合：MediatR实现CQRS解耦，Specification模式封装查询逻辑，两者配合能很好保证代码的可测试性和可维护性。

更优替代方案与最佳实践

1. Specification模式（首选）

在领域层创建规格接口与具体规格类，封装查询逻辑，仓储根据规格构建查询：

// 领域层的规格接口
public interface ISpecification<T>
{
    Expression<Func<T, bool>> Criteria { get; }
    List<Expression<Func<T, object>>> Includes { get; }
    Func<IQueryable<T>, IOrderedQueryable<T>> OrderBy { get; }
    int? Skip { get; }
    int? Take { get; }
}

// 领域层的仓储接口
public interface IOrderRepository
{
    Task<Order> GetByIdAsync(int id);
    Task<List<Order>> GetBySpecAsync(ISpecification<Order> spec);
    Task AddAsync(Order order);
    void Update(Order order);
}

// 基础设施层的EF Core实现
public class EfCoreOrderRepository : IOrderRepository
{
    private readonly AppDbContext _dbContext;

    public EfCoreOrderRepository(AppDbContext dbContext) => _dbContext = dbContext;

    public async Task<List<Order>> GetBySpecAsync(ISpecification<Order> spec)
    {
        var query = _dbContext.Orders.AsQueryable();
        // 应用查询条件
        if (spec.Criteria != null) query = query.Where(spec.Criteria);
        // 应用关联加载
        foreach (var include in spec.Includes) query = query.Include(include);
        // 应用排序
        if (spec.OrderBy != null) query = spec.OrderBy(query);
        // 应用分页
        if (spec.Skip.HasValue) query = query.Skip(spec.Skip.Value);
        if (spec.Take.HasValue) query = query.Take(spec.Take.Value);

        return await query.ToListAsync();
    }

    // 其他方法实现...
}

2. 查询对象模式（Query Object Pattern）

与Specification模式类似，但更专注复杂查询场景，每个查询对象对应一个特定查询需求，仓储根据查询对象执行对应SQL或LINQ查询。适合当Specification模式无法满足多表联合查询、聚合统计等复杂需求时使用，但复杂度略高。

3. CQRS分离读写

读操作：可直接在应用层的查询处理程序中使用EF Core查询（绕过仓储），返回DTO——因为读操作通常不需要领域逻辑，直接查询数据库能提升性能和灵活性。
写操作：仍通过仓储操作领域实体，保证业务逻辑一致性。
这种方式能进一步解耦读写逻辑，避免为读操作过度设计仓储接口。

可测试性与可维护性的保障

依赖注入：通过DI注入仓储接口，上层代码（应用服务、查询处理程序）依赖抽象而非具体实现，方便单元测试时用Mock替代真实仓储。
单一职责：仓储只负责持久化操作，不包含业务逻辑或数据转换逻辑，每个方法职责明确。
领域层隔离：领域层不依赖任何外部框架，所有持久化细节都封装在基础设施层，便于更换ORM或数据库。

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

.NET 8 Clean Architecture中合规实现Repository Pattern的最佳实践

当前架构设置 #

面临的挑战 #

我的疑问 #

我的拟议方案 #

回答 #

1. 仓储应返回领域实体还是DTO？ #

2. 仓储接口的放置位置 #

3. 仓储是否应该暴露IQueryable？ #

对你拟议方案的评价 #

更优替代方案与最佳实践 #