领域驱动设计中树形Item领域模型类如何正确使用仓储类？

核心需求与痛点 #

• Item构成递归树形结构，父项价格需等于所有后代Item的价格之和
• 叶子节点价格从数据库读取，非叶子节点价格需计算得出
• 希望在领域模型中封装价格计算逻辑，避免将业务规则写入SQL（持久层），但当前计算需要访问仓储，而领域模型直接依赖仓储会带来耦合问题

现有尝试的方案存在明显缺陷：

• 构造函数传入仓储：领域模型耦合基础设施层，违反DDD依赖倒置原则，难以独立测试
• 方法内新建仓储：硬编码实例化，无法控制生命周期，同样存在耦合
• 预加载所有后代：资源浪费，尤其树结构较深时
• 映射器用SQL计算总和：将业务逻辑转移到持久层，违背DDD领域层封装规则的核心思想

推荐解决方案 #

方案1：领域服务封装计算逻辑（最符合DDD原则） #

将价格计算逻辑从Item类分离到领域服务中，由服务依赖仓储接口，领域模型保持纯净不依赖任何基础设施。

代码示例

// 领域模型：仅封装属性与基础行为，不依赖外部依赖
public class Item
{
    public string Id { get; init; }
    public string Name { get; init; }
    public string ParentId { get; init; }
    public List<string> ChildIds { get; init; }
    // 叶子节点存储实际价格，非叶子节点为null
    public int? Price { get; init; }

    public Item(string id, string name, string parentId, List<string> childIds, int? price = null)
    {
        Id = id;
        Name = name;
        ParentId = parentId;
        ChildIds = childIds;
        Price = price;
    }
}

// 领域层定义仓储接口（依赖抽象）
public interface IItemsRepository
{
    Item GetById(string id);
    // 可选：批量获取优化性能
    IEnumerable<Item> GetByIds(IEnumerable<string> ids);
}

// 领域服务：负责封装价格计算的业务规则
public class ItemPriceCalculator
{
    private readonly IItemsRepository _itemsRepository;

    public ItemPriceCalculator(IItemsRepository itemsRepository)
    {
        _itemsRepository = itemsRepository;
    }

    public int CalculateTotalPrice(Item item)
    {
        // 叶子节点直接返回自身价格
        if (!item.ChildIds.Any())
        {
            return item.Price ?? 0;
        }

        // 递归计算所有子节点的总价格之和
        int total = 0;
        foreach (var childId in item.ChildIds)
        {
            var childItem = _itemsRepository.GetById(childId);
            total += CalculateTotalPrice(childItem);
        }
        return total;
    }
}

优势

• 领域模型保持纯净，符合DDD“领域模型封装业务规则，不依赖基础设施”的要求
• 计算逻辑集中在领域服务，便于维护与扩展
• 仓储依赖通过构造函数注入，支持单元测试（可使用Mock仓储模拟数据）
• 按需加载子节点，避免一次性加载整个树造成资源浪费

方案2：延迟加载（适合需要模型自主计算的场景） #

若需让Item类自身具备价格计算能力，可注入仓储接口（而非具体实现）实现延迟计算，需注意严格依赖抽象避免耦合。

代码示例

// 领域层仓储接口
public interface IItemsRepository
{
    Item GetById(string id);
}

public class Item
{
    private readonly IItemsRepository _itemsRepository;

    public string Id { get; init; }
    public string Name { get; init; }
    public string ParentId { get; init; }
    public List<string> ChildIds { get; init; }
    public int? Price { get; init; }

    // 注入仓储接口（依赖抽象，而非具体实现）
    public Item(string id, string name, string parentId, List<string> childIds, IItemsRepository itemsRepository, int? price = null)
    {
        Id = id;
        Name = name;
        ParentId = parentId;
        ChildIds = childIds;
        _itemsRepository = itemsRepository;
        Price = price;
    }

    // 延迟计算总价格
    public int GetTotalPrice()
    {
        if (!ChildIds.Any())
        {
            return Price ?? 0;
        }

        int total = 0;
        foreach (var childId in ChildIds)
        {
            var child = _itemsRepository.GetById(childId);
            total += child.GetTotalPrice();
        }
        return total;
    }
}

注意事项

• 必须注入领域层定义的仓储接口，而非EF等具体实现类，遵守依赖倒置原则
• 若模型需要序列化（如转换为DTO），需处理仓储实例的序列化问题
• 单元测试时可注入Mock仓储，不影响测试独立性

方案3：事件驱动预计算（适合性能敏感、变更不频繁的场景） #

如果树形结构稳定、价格变更频率低，可在叶子节点价格变更时，通过事件驱动向上更新父节点的预计算总价格，将计算逻辑从查询阶段转移到变更阶段。

实现思路

1. 叶子节点价格更新时，发布ItemPriceChangedEvent领域事件
2. 事件处理器递归遍历所有父节点，重新计算并更新其总价格，同步到数据库
3. 查询时直接读取数据库中预计算好的总价格，无需实时计算

优势

• 查询性能极高，直接读取预存值
• 业务逻辑依然封装在领域层（事件处理器属于领域层），不依赖持久层SQL
• 避免查询时的递归计算开销，适合大数据量场景

总结 #

• 优先选择领域服务方案，最贴合DDD设计原则，兼顾可维护性与可测试性
• 若需模型自主计算能力，可采用延迟加载方案，但需严格遵守依赖抽象的要求
• 性能敏感且变更不频繁的场景，推荐事件驱动预计算方案

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