ORM实体与DDD实体对比：JPA场景下领域模型落地方案咨询

核心误区纠正 #

首先JPA规范并没有要求实体必须有公共的getter/setter，仅要求实体必须存在无参构造方法（访问级别可设为protected仅供JPA反射调用），持久化注解可以标注在私有字段上，完全不需要对外暴露内部状态的修改入口，所谓「JPA天生是贫血模型」是对规范的常见误解。

方案1：单模型（领域逻辑直接写入JPA实体） #

适用场景 #

个人项目、中小型业务、迭代周期较短的系统，属于投入产出比最高的方案。

实现方式 #

• 给JPA实体添加protected级别的无参构造，仅供JPA实例化使用，对外仅暴露满足领域不变量的有参构造方法
• 完全删除公共setter方法，所有内部状态的修改只能通过实体的领域方法完成，例如订单取消逻辑不要对外暴露setStatus()，而是实现public void cancel()方法，内部先校验取消前置条件、再修改状态、生成操作日志等
• JPA注解直接标注在私有字段上，不影响持久化逻辑

层级放置 #

带JPA注解的富领域实体直接放在领域层的实体/聚合根包下，Repository接口定义在领域层，Repository实现放在基础设施层。

优劣说明 #

优势是无需维护额外映射逻辑，开发效率高；劣势是领域层会依赖JPA注解，不符合六边形架构领域层零技术依赖的要求，未来更换ORM框架时需要修改实体代码。

方案2：双模型（独立领域模型+JPA持久化模型） #

适用场景 #

大型核心业务系统、预期生命周期超过3年、业务复杂度极高的项目，追求长期可维护性优先。

实现方式 #

• 领域层存放纯POJO富领域模型，无任何框架注解，所有业务逻辑、不变量校验都在这层实现，完全不感知持久化细节
• 基础设施层存放纯贫血JPA实体，仅包含getter/setter和JPA注解，专门负责和数据库表结构映射
• 在基础设施层的Repository实现类中完成两类模型的互转：持久化时把领域模型转为JPA实体，查询时把JPA实体转为纯领域模型返回给上层

层级放置 #

• 纯POJO领域模型：领域层
• JPA持久化实体：基础设施层的持久化模块
• 模型映射逻辑：放在基础设施层的Repository实现类中，或单独抽成映射器类统一放在基础设施层
• Repository接口定义在领域层，上层仅依赖领域层接口，完全感知不到底层JPA相关实现

优劣说明 #

优势是领域层完全纯净，和持久化技术彻底解耦，更换ORM、甚至切换数据库类型都不需要修改领域层代码；劣势是需要额外维护一套模型和映射逻辑，有一定开发成本，简单项目会显得冗余。

选型建议 #

如果是个人学习项目或者小型业务，直接选用单模型方案即可，实际生产中绝大多数项目更换ORM的概率极低，少量的框架耦合带来的影响远低于双模型的额外开发成本。如果是企业级核心系统，优先选择双模型方案，解耦带来的长期维护收益远大于初期的开发投入。

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