EF Core开发是否需要分离领域模型与持久化实体？

你观察到的Jimmy Bogard、Steve 'Ardalis' Smith、Jason Taylor等开发者在示例中直接将领域模型用作EF实体，不是为了简化演示代码，这是绝大多数业务场景下的生产级最优实践。

分离领域模型与持久化实体的唯一适用场景 #

只有遇到以下两类情况时，单独定义持久化实体才有实际收益：

• 领域模型与存储结构存在本质性结构差异：比如领域层严格按聚合根边界建模、封装值对象，但数据库是历史遗留的反范式脏结构，或者同一套领域逻辑需要同时适配EF Core、MongoDB、第三方接口等多套完全异构的存储实现，需要持久化层做专门的结构适配。
• 做跨团队维护的平台级内核：领域层是独立团队迭代的核心逻辑，有严格的依赖管控要求，不允许引入任何持久化相关的技术依赖，但这类场景在普通业务开发中占比不足5%。

你感知到的变更跟踪丢失痛点完全真实 #

很多鼓吹"必须严格分层、领域模型绝对不能和持久化层有任何关联"的文章，从来不会提手动做对象图差异比对的长期维护成本：

只要聚合根新增一个关联集合、加一个值对象字段，你就得同步修改手动状态判断的逻辑，漏改一个属性就会出现更新丢失、或者全字段全表更新的问题，长期迭代下来的bug率、维护成本远高于直接复用实体的方案。

你目前的使用方式本身已经满足解耦要求：

• 你没有在实体类上加任何EF Core相关的数据注解，所有映射配置全通过Fluent API写在Infrastructure层，领域层本身没有引入EF Core的依赖，架构解耦看的是依赖方向是否正确，不是看是不是用了同一个类。
• 直接复用领域模型的收益是实打实的：EF Core自动变更跟踪、自动生成高效的增量更新SQL、不用写两层模型的双向映射逻辑、不用维护冗余的状态判断代码，开发效率和运行时性能都更高。

你当前三类模型的调整建议 #

• API.Models：这层必须保留，作为接口层的请求/响应DTO使用，绝对不要直接把领域实体暴露给外部接口，否则接口字段会跟着领域模型随意变动，直接破坏对外兼容性。
• Core.Models：如果这层是你存放聚合根、值对象、领域业务逻辑的核心层，完全可以直接被EF Core映射配置使用，没必要额外定义一套结构完全一致的Infrastructure.Entities做重复劳动。
• 不要为了"架构看起来规整纯粹"做无意义的抽象：不少教程把分层本身当成了目的，每层都套一层一模一样的模型，本质是增加无效代码量，没有任何实际收益。

最后补一个常见误区：很多人担心EF Core会给实体加动态代理、注入持久化逻辑污染领域模型，这个问题只要你使用无代理跟踪、坚持用Fluent API做配置、不在领域类里写持久化相关的逻辑，就完全可以避免，你现在的配置方式已经解决了这个问题。
如果没有遇到前面提到的必须分离的特殊场景，直接复用领域模型作为EF实体就好，这不是偷懒，是经过大量生产项目验证的务实选择。

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