在DDD+EF Core中，领域实体复用与映射类分离该选哪种？

常用方案 #

在DDD实践中，**方案1（直接用聚合根/子实体映射数据库表）**是行业内的主流选择，仅在对领域层纯净度有极高要求、或数据库结构与领域模型差异极大的场景下，才会考虑方案2。

方案1：直接映射聚合根/子实体 #

实现示例 #

领域模型：

public class User : AggregateRoot 
{
    string Name { get; }
    string Email { get; }

    // 领域逻辑...
}

EF Core配置：

public class EntityTypeConfiguration : IEntityTypeConfiguration<User> 
{
    public void Configure(EntityTypeBuilder<User> builder) 
    {
        // 属性映射逻辑...
    }
}

优点 #

• 无冗余代码：领域模型与持久化实体合二为一，无需维护重复属性，省去对象映射的额外工作
• 逻辑内聚：领域逻辑与持久化配置紧密关联，修改业务属性时只需同步更新一处，避免不一致
• 低维护成本：减少类文件数量，新增/修改字段时无需同步多份代码，降低出错概率

缺点 #

• 边界模糊：领域模型可能会被EF Core的持久化细节侵入，比如为了映射需要添加无参构造函数、调整属性访问权限（虽然EF Core支持私有构造和属性，但仍会对领域模型的纯粹性有轻微影响）
• 结构复杂度提升：大型项目中，领域层会混入持久化配置代码，可能让领域逻辑的可读性下降

方案2：分离领域模型与数据库实体 #

实现示例 #

领域模型：

public class User : AggregateRoot 
{
    string Name { get; }
    string Email { get; }

    // 领域逻辑...
}

数据库实体：

public class UserTable 
{
    Guid Id { get; }
    string Name { get; }
    string Email { get; }

    // 无业务逻辑
}

EF Core配置：

public class EntityTypeConfiguration : IEntityTypeConfiguration<UserTable> 
{
    public void Configure(EntityTypeBuilder<UserTable> builder) 
    {
        // 属性映射逻辑...
    }
}

仓储层映射示例：

Add(User user) 
{
    var entity = user.MapToUserTable(); // 通过Mapster/AutoMapper实现映射
    dbContext.Users.Add(entity);
    // 持久化逻辑...
}

优点 #

• 职责完全隔离：领域模型专注于业务逻辑，不受EF Core持久化规则的约束；数据库实体仅负责与表结构映射，职责单一
• 结构清晰：数据库实体可统一放在EFCoreEntities这类专用文件夹中，领域层保持纯净，便于团队分工维护
• 高灵活性：当数据库表结构与领域模型差异较大时，可独立调整数据库实体，无需修改领域模型

缺点 #

• 代码冗余：两套类的属性高度重复，增加项目代码量
• 额外映射成本：需要维护AutoMapper/Mapster的映射规则，新增或修改属性时必须同步更新映射配置，容易出现遗漏
• 性能损耗：大量对象转换时会产生轻微的性能开销，虽然多数场景下可忽略，但高并发场景下需谨慎评估

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