Clean Architecture：跨多项目复用generic repository接口是否可行？

完全可行，而且这正是Clean Architecture核心思想的典型落地场景。

为什么符合Clean Architecture #

Clean Architecture的核心是依赖倒置原则：高层模块（业务逻辑）不依赖底层模块（数据实现），两者都依赖抽象。通用仓库接口属于抽象层范畴，本身就应该是可复用的——把它放在独立的共享类库（比如命名为Core.Abstractions或Domain.Repositories）中，让Shipment API、Products API等多个业务项目依赖这个抽象类库，完全符合架构的依赖规则。

具体实践要点 #

• 接口聚焦通用需求：只定义所有业务模块都需要的基础CRUD方法，别为了通用而过度设计。比如只保留GetByIdAsync、AddAsync这类通用操作，避免加入特定业务的查询逻辑。
• 各自实现具体仓库：虽然接口共用，但不同API的数据源可能不同（比如Shipment用SQL Server，Products用PostgreSQL），每个项目只需针对自己的领域实体实现通用接口，通过依赖注入注入到业务逻辑中即可。
• 添加泛型约束：给泛型接口加上约束（比如where T : class, IEntity），确保只有领域实体才能使用该仓库，避免滥用，保持领域模型的纯净性。

示例代码 #

共享类库中的接口定义 #

public interface IGenericRepository<T> where T : class, IEntity
{
    Task<T?> GetByIdAsync(Guid id);
    Task<IEnumerable<T>> GetAllAsync();
    Task AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(T entity);
}

// 定义实体标记接口
public interface IEntity
{
    Guid Id { get; set; }
}

Shipment API中的具体实现 #

public class ShipmentRepository : IGenericRepository<Shipment>
{
    private readonly ShipmentDbContext _dbContext;

    public ShipmentRepository(ShipmentDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<Shipment?> GetByIdAsync(Guid id)
    {
        return await _dbContext.Shipments.FindAsync(id);
    }

    // 其他接口方法的实现省略
}

Products API中的实现逻辑类似 #

只需替换为自己的ProductDbContext和Product实体即可，接口完全复用。

注意事项 #

• 避免混入技术细节：别在通用接口里暴露EF Core的DbSet、LINQ特定方法等技术细节，保持接口的抽象性。这样后续更换ORM框架时，不需要修改接口，只需要替换实现类。
• 通用仓库≠万能仓库：对于复杂的业务查询（比如多表关联、聚合统计），建议单独定义专用仓库接口（比如IShipmentTrackingRepository），不要强行塞进通用仓库，避免接口膨胀、职责不清。

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