基于MVC 5与EF 6的DDD模式落地困惑求助

兄弟，我太懂你这种困惑了——当初我第一次在MVC5+EF6里折腾DDD的时候，也盯着领域模型和EF实体模型愣了半天，感觉这俩简直是复制粘贴出来的，拆分来拆分去都像多此一举。结合我踩过的坑，给你捋捋怎么落地，以及为啥你会觉得它们是“复刻”：

大概率是因为你把EF的实体直接当成了领域模型的“模板”，或者当前业务逻辑还足够简单，导致领域模型的价值没体现出来。先别急着否定DDD，先把这俩的本质差异掰清楚：

• EF实体（Entity Model）：纯粹是数据库的“镜像”，只负责和数据库交互，带的都是EF的特性（比如[Key]、[ForeignKey]），没有任何业务行为。
• 领域模型（Domain Model）：业务规则的“容器”，是整个系统的核心。哪怕现在业务简单，它也得是独立的——这是为未来复杂业务留的扩展空间。

给你一套我亲测有效的步骤，一步步来就不会乱：

1. 先把领域层彻底独立出来 #

领域层必须是一个纯类库，完全不依赖EF！里面只放领域模型、领域服务、值对象这些核心业务代码，连EF的引用都别加。比如：

// 领域模型：只关心业务规则，无EF特性
public class Order
{
    public Guid Id { get; private set; }
    public decimal TotalAmount { get; private set; }
    public OrderStatus Status { get; private set; }
    public Address ShippingAddress { get; private set; }

    // 业务行为：封装订单确认的规则
    public void Confirm()
    {
        if (Status != OrderStatus.Created)
            throw new InvalidOperationException("只有未确认的订单才能执行此操作");
        Status = OrderStatus.Confirmed;
    }

    // 私有构造+工厂方法：保证领域模型的完整性
    private Order(Guid id, decimal totalAmount, OrderStatus status)
    {
        Id = id;
        TotalAmount = totalAmount;
        Status = status;
    }

    public static Order Create(decimal totalAmount, Address shippingAddress)
    {
        if (totalAmount <= 0)
            throw new ArgumentException("订单金额不能为0或负数");
        return new Order(Guid.NewGuid(), totalAmount, OrderStatus.Created)
        {
            ShippingAddress = shippingAddress
        };
    }
}

// 值对象：无唯一标识，纯值类型，用于封装业务属性
public class Address
{
    public string Street { get; }
    public string City { get; }

    public Address(string street, string city)
    {
        if (string.IsNullOrWhiteSpace(street))
            throw new ArgumentException("街道地址不能为空");
        Street = street;
        City = city;
    }
}

2. 用EF实体做“持久化模型”，和领域模型做映射 #

EF的实体只负责和数据库打交道，和领域模型是两个独立的东西，需要做映射转换（手动写或者用AutoMapper都行）：

// EF实体：只关心数据库映射，带EF特性
public class OrderEntity
{
    [Key]
    public Guid Id { get; set; }
    public decimal TotalAmount { get; set; }
    public int Status { get; set; } // 用int存枚举，EF更友好
    public string ShippingStreet { get; set; }
    public string ShippingCity { get; set; }
}

// 映射逻辑：可以放在基础设施层
public static OrderEntity ToEntity(this Order order)
{
    return new OrderEntity
    {
        Id = order.Id,
        TotalAmount = order.TotalAmount,
        Status = (int)order.Status,
        ShippingStreet = order.ShippingAddress.Street,
        ShippingCity = order.ShippingAddress.City
    };
}

public static Order ToDomain(this OrderEntity entity)
{
    var address = new Address(entity.ShippingStreet, entity.ShippingCity);
    var order = Order.Create(entity.TotalAmount, address);
    // 反射或私有构造赋值Id和Status（或者调整工厂方法兼容）
    typeof(Order).GetProperty(nameof(Order.Id)).SetValue(order, entity.Id);
    typeof(Order).GetProperty(nameof(Order.Status)).SetValue(order, (OrderStatus)entity.Status);
    return order;
}

3. 把EF的DbContext放在基础设施层 #

基础设施层负责数据访问、外部调用这些“脏活”，它可以引用EF和领域层。DbContext只操作EF实体：

public class AppDbContext : DbContext
{
    public DbSet<OrderEntity> Orders { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        // 配置数据库映射规则，比如表名、字段长度
        modelBuilder.Entity<OrderEntity>().ToTable("Orders");
        modelBuilder.Entity<OrderEntity>().Property(x => x.ShippingStreet).HasMaxLength(200);
    }
}

4. MVC层只依赖领域层，不直接碰EF #

MVC控制器调用领域服务，领域服务再通过仓储接口操作数据——仓储的接口定义在领域层，实现放在基础设施层，这样就解耦了：

// 领域层的仓储接口：只定义业务需要的方法
public interface IOrderRepository
{
    void Save(Order order);
    Order GetById(Guid id);
}

// 基础设施层的仓储实现：用EF操作数据库
public class EfOrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;

    public EfOrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Save(Order order)
    {
        var entity = order.ToEntity();
        _context.Orders.AddOrUpdate(entity);
        _context.SaveChanges();
    }

    public Order GetById(Guid id)
    {
        var entity = _context.Orders.Find(id);
        return entity?.ToDomain();
    }
}

// MVC控制器：只和领域层交互
public class OrdersController : Controller
{
    private readonly IOrderRepository _orderRepo;

    public OrdersController(IOrderRepository orderRepo)
    {
        _orderRepo = orderRepo;
    }

    public ActionResult Confirm(Guid id)
    {
        var order = _orderRepo.GetById(id);
        if (order == null) return NotFound();
        
        try
        {
            order.Confirm();
            _orderRepo.Save(order);
            return RedirectToAction("Details", new { id });
        }
        catch (InvalidOperationException ex)
        {
            ModelState.AddModelError("", ex.Message);
            return View("Details", order);
        }
    }
}

等你的业务逻辑变复杂，你就会发现它们的差异越来越大：

• 领域模型里的值对象（比如Address），在EF实体里会拆成单独的字段存在同一张表；
• 领域模型的聚合根会封装聚合内的规则，而EF实体只关心数据库的关联关系；
• 复杂的业务规则（比如订单折扣、库存扣减）都会封装在领域模型里，不会出现在控制器或EF实体中。

如果当前业务确实很简单，没必要强行搞复杂的DDD，但至少要把领域层和EF实体分开——这不是为了跟风，而是为未来的业务扩展留好后路。DDD是解决复杂业务的工具，不是必须套在所有项目上的银弹。

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