c#如何实现领域驱动设计DDD_c#领域驱动设计DDD的几种常见用法-C#.Net教程-PHP中文网

DDD落地必须严守三原则：领域模型不依赖EF Core，仓储接口不返回IQueryable或DTO，应用服务不写业务判断逻辑；否则仅为披皮CRUD。

c#如何实现领域驱动设计ddd_c#领域驱动设计ddd的几种常见用法

领域模型不能直接依赖 EF Core，仓储接口不能返回 IQueryable 或 DTO，应用服务里不该写业务判断逻辑——这三点踩错任意一个，DDD 就只是披了层皮的 CRUD。

领域实体里别调用 `SaveChanges()`

常见错误现象：在 User.ConfirmEmail() 方法里直接注入 _context 并调用 SaveChanges()；或者在 Order.AddLineItem() 里更新状态后立刻持久化。

这样做会把基础设施细节泄漏进领域层，导致：

换数据库（比如从 SQL Server 切到 Cosmos DB）时，整个领域模型要重写
无法做事件溯源或审计日志，因为保存动作和业务动作耦合在一起
单元测试必须启动真实数据库，User 类失去可测试性

正确做法是让领域实体只管“能不能做”和“做了之后变什么样”：

public class Order
{
    public OrderId Id { get; private set; }
    public OrderStatus Status { get; private set; }
    private List<orderitem> _items = new();

    public void Confirm()
    {
        if (Status != OrderStatus.Draft)
            throw new InvalidOperationException("Only draft orders can be confirmed");

        Status = OrderStatus.Confirmed;
        // 不做任何 Save、不碰 DbContext、不发事件
    }
}</orderitem>

保存动作交给应用服务统一协调，由仓储实现落地。

仓储接口只能返回领域对象，不能暴露查询能力

错误示例：IOrderRepository.FindByCustomerId(int id) 返回 IQueryable，或更糟——返回 OrderDto。

为什么危险：

IQueryable 把 LINQ 表达式树泄漏到上层，应用服务可能写出 .Where(...).OrderBy(...).Skip(...).Take(...)，仓储就不再是“按 ID 加载/保存聚合”的抽象，而退化成数据访问层包装
返回 OrderDto 意味着领域层开始为展示层妥协，值对象、不变量、业务约束全被绕过
后续加缓存、读写分离、CQRS 时，所有地方都要改

推荐做法：仓储只提供明确语义的方法，复杂查询走 Specification：

public interface IOrderRepository
{
    Order GetById(OrderId id);
    void Add(Order order);
    void Update(Order order);
}

// 非仓储接口，专用于查询
public interface IOrderQueryService
{
    IEnumerable<order> Match(Specification<order> spec);
}</order></order>

Specification 实现类（如 ConfirmedOrdersSinceSpec）负责封装条件，由 IOrderQueryService 翻译成 SQL，领域层完全无感。