仓储模式疑问：读取完整领域对象是否属于不良设计？

你提出的这个问题绝对是DDD和仓储模式实践中最常见的痛点之一——很多人一开始都会陷入“仓储必须返回完整领域对象”的误区，进而担心数据冗余和性能问题。其实你并没有忽略核心逻辑，只是对仓储模式的实现细节理解得有点片面，咱们一步步拆解：

1. 仓储并非只能返回“全量填充”的领域对象 #

首先要明确：仓储的职责是封装数据访问逻辑，而非强制返回100%属性都填充的领域对象。你完全可以为仓储设计针对性的查询方法，只加载上层需要的属性，再构造出部分填充的领域对象。

举个C#的例子，假设你的Employee领域对象有40个属性，但视图层只需要ID、姓名、邮箱、部门ID和入职日期：

public class EmployeeRepository : IEmployeeRepository
{
    private readonly AppDbContext _dbContext;

    public EmployeeRepository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    // 专门用于列表展示的查询方法，只加载需要的字段
    public Employee GetEmployeeBasicInfo(int employeeId)
    {
        var employeeData = _dbContext.Employees
            .Where(e => e.Id == employeeId)
            .Select(e => new 
            { 
                e.Id, 
                e.Name, 
                e.Email, 
                e.DepartmentId, 
                e.HireDate 
            })
            .FirstOrDefault();

        if (employeeData == null)
            throw new EmployeeNotFoundException(employeeId);

        // 构造领域对象，只填充需要的属性
        var employee = new Employee(employeeData.Id, employeeData.Name, employeeData.Email)
        {
            DepartmentId = employeeData.DepartmentId,
            HireDate = employeeData.HireDate
        };

        return employee;
    }
}

这样一来，数据库只会返回5个字段的数据，网络传输的冗余量就被降到了最低，同时返回的依然是合法的领域对象——上层使用时只需要用到已填充的属性即可，未填充的属性可以设为默认值或者标记为“未加载”（如果你的领域对象有这样的状态标识）。

2. 用CQRS思想区分“命令”与“查询”场景 #

你提到增删改需要完整对象，这完全正确——因为命令操作（比如更新员工的薪资、修改部门）需要依赖领域对象的业务逻辑（比如薪资不能低于最低工资标准），这时候必须加载完整的领域对象来保证业务规则的执行。

但查询操作（比如列表展示、详情预览）不需要触发业务逻辑，只需要展示数据。这时候你可以：

• 为仓储设计专门的查询方法（就像上面的例子），返回部分填充的领域对象
• 甚至可以在应用层将部分填充的领域对象转换为DTO供视图层使用——注意，这是应用层的职责，而非仓储的，仓储依然只返回领域对象，符合你提到的“仓储不应返回DTO”的原则

3. 避免通用泛型仓储的误用 #

很多开发者会贪图方便，实现一个通用的Repository<T>，只提供GetById、Add等基础CRUD方法，这种做法很容易导致“每次都返回完整对象”的问题。

正确的做法是：为每个领域实体设计专用的仓储接口，比如IEmployeeRepository，并在其中定义该实体所需的所有查询方法——这些方法都是针对具体业务场景的，而非通用的。这样你就能精准控制每个查询返回的数据量，同时保持仓储的抽象性。

4. 为什么不能用IQueryable？ #

你提到仓储不应使用IQueryable，这个观点非常正确。因为IQueryable会将查询逻辑泄露到上层，比如应用层可能会写repository.GetAll().Where(e => e.Salary > 10000).OrderBy(e => e.Name)，这会让上层代码直接依赖底层数据库的查询语法（比如EF Core的Linq Provider），破坏了仓储的抽象性——如果以后更换数据库（比如从SQL Server换成MongoDB），上层代码可能需要大量修改。

而通过在仓储中定义具体的查询方法，你可以把所有数据库相关的逻辑封装在仓储内部，上层只需要调用方法即可，完全不需要关心底层是怎么实现的。

总结 #

你担心的“百万级数据传输时丢弃大量数据”确实是不良设计，但这不是仓储模式本身的问题，而是错误的仓储实现方式导致的。只要你：

• 为仓储设计针对性的查询方法，只加载需要的字段
• 区分命令和查询场景，按需返回部分或完整的领域对象
• 避免通用泛型仓储的误用，采用领域专用仓储

就能既遵守“仓储返回领域对象、不使用IQueryable”的原则，又能避免数据冗余和性能问题。

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