DDD+CQRS场景下含计算属性的领域模型设计与查询效率平衡咨询

下面是针对这类问题的实用解决方案，都是业内常用的最佳实践：

1. 把领域计算逻辑抽成纯函数 #

把实体里的IsActive这类计算逻辑抽离成独立的纯函数，既保留领域逻辑的统一封装，又能在查询侧直接复用，不用加载完整聚合。

示例代码：

public static class EntityDomainRules
{
    public static bool IsEntityActive(bool isDisabled, DateTime expiryDate, bool ownerIsActive)
    {
        return !isDisabled && expiryDate > DateTime.UtcNow && ownerIsActive;
    }
}

实体里的方法可以改成调用这个纯函数：

public bool IsActive() 
{
    return EntityDomainRules.IsEntityActive(_disabled, expiryDate, _owner.IsActive);
}

查询侧加载DTO时，只要拿到所需的字段值，就能直接调用这个函数计算结果，不用加载整个聚合根。

2. 让查询侧直接复用领域逻辑 #

根据数据量和查询场景，有两种实现方式：

• 内存计算：如果查询返回的DTO已经包含计算所需的所有字段（比如从数据库直接查Disabled、ExpiryDate、OwnerIsActive），直接调用纯函数算出IsActive，完全不用碰领域实体。
• 数据库层计算：如果数据量极大，内存计算效率低，就把纯函数的逻辑转成SQL或者ORM的查询表达式，让数据库直接计算并返回结果。比如用EF Core：

  var activeDtos = dbContext.Entities
      .Where(e => !e.Disabled && e.ExpiryDate > DateTime.UtcNow && e.Owner.IsActive)
      .Select(e => new EntityDto 
      { 
          Id = e.Id, 
          IsActive = !e.Disabled && e.ExpiryDate > DateTime.UtcNow && e.Owner.IsActive 
      })
      .ToList();
  

  这里要注意：必须保证数据库层的逻辑和纯函数的逻辑完全一致，避免出现数据不一致的情况。

3. 用CQRS读模型预计算结果 #

如果这个计算属性的查询频率很高，而且计算逻辑相对稳定，最省心的方式是在命令侧提前算好结果，写到读模型里。

• 当实体的状态变化时（比如禁用、过期时间修改、所有者状态变更），触发对应的领域事件。
• 读模型订阅这些事件，重新计算IsActive的值，然后更新读库中对应的字段。
• 查询侧直接从读模型读取预计算好的IsActive，不用做任何计算，性能拉满。

4. 调整聚合边界或冗余必要字段 #

如果计算逻辑依赖了跨聚合的实体（比如例子里的_owner.IsActive），可以重新审视聚合边界：

• 如果Owner不属于当前聚合的必要依赖，考虑把Owner的IsActive状态冗余到当前实体里，比如加一个OwnerIsActive字段。
• 当Owner的状态变化时，通过领域事件同步更新这个冗余字段，这样查询时就不用加载整个Owner实体，减少数据加载量。

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