Clean Architecture中上下文使用及领域模型设计问题咨询

架构老林

2026-9-2

核心结论

绝对不要将DbContext传入领域模型方法，该做法确实会破坏Clean Architecture的依赖规则，造成层与层的强耦合。
领域模型不应该设计为贫血模型，内聚可复用的业务逻辑正是领域层的核心价值。

问题原因拆解

你现在遇到的删除逻辑需要依赖Context的问题，本质是混淆了领域状态变更和持久化实现两个不同层面的职责：
Clean Architecture的核心依赖规则是：内层（领域层）不得依赖外层（应用层、基础设施层）的具体实现。DbContext是基础设施层的EF Core持久化实现细节，一旦传入领域层，会直接导致领域模型和特定ORM、数据库实现强绑定，后续做单元测试、替换持久化方案时会遇到极大阻碍。

而你现在写的新增、编辑方法不需要传Context的实现方向是完全正确的：领域模型本身只需要负责维护内存中的自身状态、执行对应的业务规则校验，根本不需要感知数据库的存在。删除逻辑同理，你不需要在领域层手动调用Context的Remove方法——EF Core自带变更追踪能力，只要你在领域模型中把待删除的标签从实体的标签集合中移除，正确配置实体间的级联关系后，调用SaveChangesAsync时EF Core会自动识别被移除的实体，生成对应的DELETE语句完成持久化。

贫血模型的判断

不要把领域模型做成只有get/set属性的贫血模型。贫血模型本质是把所有业务逻辑散落在应用层的各个Handler中，一旦同类逻辑需要在多个场景复用，很容易出现重复代码、规则不一致的问题，后期维护成本会指数级上升。
应用层Handler的职责是做流程协调：比如查询实体、做权限校验、组装参数、调用领域方法、触发持久化、发布领域事件，不要把核心业务规则、状态修改的逻辑写在Handler里。

修正后的实现参考

领域层实体方法（无任何外部依赖）

// 标签集合建议作为实体的私有字段，不对外公开可遍历的集合引用，保证封装性
private readonly List<RestaurantTag> _tags = new();

public void AddRestaurantTags(IEnumerable<RestaurantTag> addedTags)
{
    // 此处执行领域规则校验：例如标签数量上限、单餐厅下标签名不能重复等
    foreach (var tag in addedTags)
    {
        _tags.Add(tag);
    }
}

public void DeleteRestaurantTags(IEnumerable<Guid> deletedTagIds)
{
    // 此处执行领域规则校验：例如标签是否存在、是否为系统内置不可删除标签等
    var tagsToRemove = _tags.Where(t => deletedTagIds.Contains(t.Id)).ToList();
    foreach (var tag in tagsToRemove)
    {
        _tags.Remove(tag);
    }
}

public void EditRestaurantTags(IEnumerable<(Guid TagId, string NewName)> editedTags)
{
    // 此处执行领域规则校验：例如修改后的标签名是否和现有标签重名等
    foreach (var (tagId, newName) in editedTags)
    {
        var targetTag = _tags.First(t => t.Id == tagId);
        targetTag.UpdateName(newName);
    }
}

应用层Handler代码

// 1. 流程协调：查询目标实体
var entity = await _restaurantRepository.GetByIdAsync(request.RestaurantId, cancellationToken);

// 2. 应用层逻辑：参数格式校验、操作权限校验等
if (entity == null) throw new NotFoundException();

// 3. 调用领域方法完成状态变更，不需要传入Context
entity.AddRestaurantTags(tagsChanges.Added);
entity.DeleteRestaurantTags(tagsChanges.Deleted);
entity.EditRestaurantTags(tagsChanges.Edited);

// 4. 持久化：EF Core自动追踪所有状态变更，生成对应增/改/删SQL
await _context.SaveChangesAsync(cancellationToken);

特殊场景处理

如果遇到部分领域逻辑确实需要访问外部资源（例如校验标签名全局唯一，需要查询其他餐厅的标签数据），也不要直接传入DbContext：

在领域层定义抽象接口（例如ITagUniquenessChecker），声明需要的方法
在基础设施层实现该接口，内部注入DbContext完成查询
调用领域方法时，将接口的实现实例通过参数传入，保证领域层只依赖抽象，不依赖具体实现。

这种写法既可以满足领域逻辑的外部访问需求，也不会破坏分层的依赖规则，同时单元测试时可以轻松Mock接口实现，不需要依赖真实数据库。

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

Clean Architecture中上下文使用及领域模型设计问题咨询

领域层实体方法（无任何外部依赖） #

应用层Handler代码 #

领域层实体方法（无任何外部依赖）

应用层Handler代码