基于遗留数据库的DDD领域模型如何实现持久化无知？

这种遗留数据库和DDD领域模型的冲突真的是日常开发里的痛点——既要保持领域模型的纯净，又要兼容没法动的老数据库，确实头疼。我来分享下我在类似场景里的解决方案，核心就是把持久化相关的逻辑彻底从领域层剥离，让你的Entity完全不知道数据库的存在。

1. 先保留纯净的领域实体 #

首先，你的领域模型应该只关心业务规则，完全不涉及任何持久化细节。回到你最开始的干净设计，只保留业务必需的构造函数和属性，EF需要的无参构造可以偷偷加个私有的（EF通过反射能访问，不会污染领域逻辑）：

// 领域层 - 完全持久化无知的实体
public class Entity { 
    // 私有无参构造，仅EF使用，领域代码不会调用它
    private Entity() { }

    // 业务侧唯一合法的构造函数，确保实体创建符合业务规则
    public Entity(ValueType key) { 
        Key = key ?? throw new ArgumentNullException(nameof(key));
        // 这里可以加其他业务校验逻辑，比如key的合法性检查
    } 

    // 只读的业务主键，完全基于领域ValueType
    public ValueType Key { get; } 

    // 其他业务属性和方法，只和业务规则相关...
}

2. 用EF值转换器（ValueConverter）处理类型映射 #

EF的ValueConverter是解决这种“领域类型和数据库类型不匹配”问题的利器——它能在EF读写数据库时，自动完成领域类型（ValueType）和数据库存储类型（字符串）的转换，完全不用在实体里加StoredKey这种存储相关的属性。

第一步：定义值转换器 #

把转换逻辑封装到基础设施层的转换器里，领域层完全不用知道：

// 基础设施层 - EF专属的类型转换器
public class ValueTypeToStringConverter : ValueConverter<ValueType, string> {
    public ValueTypeToStringConverter() 
        : base(
            // 领域类型转数据库存储的字符串
            domainValue => domainValue.ToString(), 
            // 数据库字符串转领域类型
            dbValue => ValueType.Parse(dbValue)
          ) { }
}

如果你的ValueType序列化/反序列化逻辑比较复杂（比如不是简单的ToString和Parse），可以把这部分逻辑移到ValueType自身（保持领域逻辑内聚）：

// 领域层 - ValueType自身负责序列化/反序列化
public record ValueType(Guid BusinessId, string TenantCode) {
    // 领域侧的解析方法，处理复杂字符串格式
    public static ValueType FromStoredString(string storedValue) {
        var parts = storedValue.Split('|');
        if (parts.Length != 2 || !Guid.TryParse(parts[0], out var id)) {
            throw new InvalidOperationException("无效的存储主键格式");
        }
        return new ValueType(id, parts[1]);
    }

    // 领域侧的序列化方法
    public string ToStoredString() => $"{BusinessId}|{TenantCode}";
}

对应的转换器就可以改成：

public class ValueTypeToStringConverter : ValueConverter<ValueType, string> {
    public ValueTypeToStringConverter() 
        : base(
            domainValue => domainValue.ToStoredString(), 
            dbValue => ValueType.FromStoredString(dbValue)
          ) { }
}

第二步：在DbContext中配置映射 #

接下来在EF的上下文配置里，给Entity的Key属性绑定这个转换器，同时指定数据库列名（如果和领域属性名不一致的话）：

// 基础设施层 - DbContext配置
public class YourDbContext : DbContext {
    public DbSet<Entity> Entities { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder) {
        modelBuilder.Entity<Entity>(entity => {
            // 配置主键为领域的ValueType属性
            entity.HasKey(e => e.Key);
            
            // 绑定值转换器，指定数据库列名（对应遗留库的字符串列）
            entity.Property(e => e.Key)
                  .HasConversion<ValueTypeToStringConverter>()
                  .HasColumnName("StoredKey"); // 这里填数据库里的实际列名
            
            // 其他业务属性的配置...
        });
    }
}

3. 为什么这能实现持久化无知？ #

• 领域层的Entity完全不知道数据库的存在：它没有任何存储相关的属性（比如StoredKey），也不关心主键在数据库里是字符串还是其他类型，只专注于业务规则。
• 所有持久化适配逻辑都隔离在基础设施层：如果后续数据库结构变化（比如主键改成其他类型），只需要修改转换器或DbContext配置，完全不用动领域模型。
• 实体的创建仍然受业务规则约束：只有带ValueType参数的公共构造函数是业务侧可访问的，确保实体不会被非法创建。

应对更复杂场景的扩展思路 #

如果你的遗留数据库有更复杂的映射需求（比如单表对应多个领域实体、嵌套对象的存储等），可以继续用EF的实体类型配置、Owned Types或者Repository模式进一步隔离：

• 用IEntityTypeConfiguration把每个实体的映射逻辑拆分成单独的类，保持DbContext干净。
• 用Owned Types处理领域中的值对象，映射到数据库的多个列。
• 封装Repository接口在领域层，实现放在基础设施层，让领域层通过接口访问数据，完全屏蔽EF的细节。

内容的提问来源于stack exchange，提问作者Daniel García Rubio