Clean Architecture(DDD)中领域对象(DB Entities)与DbContext分属不同项目的原因？

我理解抽象、关注点分离以及单元测试的必要性，但将实体和上下文拆分到两个项目中的设计，在我看来似乎有些过度设计。我可能遗漏了某些核心设计考量，请问这种设计是为了方便后续适配不同的ORM吗？恳请大家予以解答，非常感谢。

适配不同ORM确实是这类设计的考量之一，但远不是全部核心原因。这类拆分的价值大多落在中大型项目长期迭代的架构灵活性和可维护性上，常见的设计考量还有以下几点：

• 纯领域模型隔离：实体项目通常仅包含纯业务定义的领域实体、值对象、领域规则、领域事件等内容，完全不依赖任何ORM、数据库或其他基础设施层组件。这可以保证你的核心业务逻辑完全和技术实现解耦，后续不管是更换ORM、切换数据库类型，甚至把单体拆分为微服务，核心业务代码都不需要做任何修改。
• 架构依赖约束：如果实体和ORM上下文放在同一个项目中，开发过程中很容易出现不合理的耦合，比如在实体中直接注入上下文做数据查询、把持久化逻辑写到实体类里。拆分到两个项目后可以通过项目依赖规则强制要求「上下文项目依赖实体项目，实体项目不依赖任何基础设施相关项目」，从架构层面杜绝不合理的依赖方向。
• 多场景复用：如果项目后续要做读写分离、接入消息消费服务、批量数据处理任务、第三方业务集成组件，这些场景只需要引用体积极小的实体项目即可，不需要引入整套ORM、数据库驱动等无关依赖，既减少引入依赖的体积和风险，也避免基础设施配置变动影响这些上层组件。
• 单元测试轻量化：拆分后针对领域逻辑编写单元测试时，不需要加载任何ORM组件、也不需要Mock数据库相关依赖，直接实例化实体就可以完成测试，测试运行效率会大幅提升，测试用例也完全不会受ORM版本迭代、配置调整的影响。
• 团队分工边界清晰：如果是大团队协作项目，通常负责核心业务规则的团队和负责数据存取、基础设施建设的团队是分开的，拆分项目后两个团队可以独立迭代各自负责的内容，避免基础设施层的改动误影响核心业务逻辑。

当然这类拆分并非所有项目都适用，如果是小体量的短期项目、内部工具类项目，未来不会有大幅架构调整的需求，这种拆分确实属于过度设计。但如果是需要长期迭代、业务逻辑复杂的中大型项目，拆分带来的长期收益远高于初期多创建一个项目的成本。

内容的提问来源于stack exchange，提问作者Zoran Bošnjak