贫血模型与充血模型的选择取决于团队认知、业务复杂度、协作边界和演进节奏；多数项目初期用贫血模型，中后期在关键领域逐步转向充血模型才是现实路径。
贫血模型和充血模型的选择，核心不在于“哪个更高级”，而在于**团队认知、业务复杂度、协作边界和演进节奏**。多数项目初期用贫血模型更稳妥，中后期在关键领域逐步转向充血模型，才是现实可行的设计路径。
贫血模型：适合快速交付与分层隔离的场景
贫血模型指 Domain Object 仅包含字段和 getter/setter，业务逻辑集中在 Service 层。它不是“错误”，而是明确的权衡结果。
- 适用情况：CRUD 主导、业务规则简单、团队对 DDD 理解不深、需要与 MyBatis/JPA 等 ORM 框架深度配合、前后端强契约（如 DTO 直接映射）
- 设计要点：避免 Service 类爆炸——按用例（Use Case）而非实体组织 Service 方法；用 Command/Query 明确分离写操作与读操作；把校验、转换、补偿等横切逻辑抽成独立组件，别堆在 Service 里
- 注意陷阱：不要让 Service 变成“上帝类”；避免在多个 Service 中重复实现同一段业务规则；警惕“伪领域对象”——比如一个 User 类有 setXXX() 却永远不调用，只是传参容器
充血模型：适合高内聚、强约束、需长期演进的核心域
充血模型要求领域对象自己封装状态与行为，方法体现业务意图（如 user.applyForLeave(startDate, endDate)），而非暴露 setter。
- 适用情况：存在明确不变量（如“账户余额不能为负”）、状态流转复杂（如订单生命周期）、规则频繁变化且影响多个用例、团队已具备领域建模能力
- 设计要点：从最小闭环开始——先选一个高价值、低依赖的子域（如优惠券发放规则）做充血；用 private 字段 + 领域方法控制状态变更入口；构造函数/静态工厂确保对象创建即合法；避免让 Entity 承担非本职职责（如持久化、日志、RPC 调用）
- 常见误用：强行给所有 POJO 加业务方法，导致贫血变“半血”；在 Entity 里直接调用 Service 或 Mapper；忽略持久化透明性——JPA/Hibernate 仍可配合充血模型，但需用 @Access(AccessType.PROPERTY) 等方式适配
混合使用：现实中更常见的合理形态
一个系统不必全盘贫血或全盘充血。关键是在边界处做好职责划分和转换。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 分层混用：DTO/VO 保持贫血（纯数据载体）；Application 层用 Command/Event 协调流程；Domain 层对核心实体采用充血，对只读或临时计算对象继续贫血
- 模块混用：用户中心用充血（关注身份、权限、状态一致性）；日志中心、配置中心等基础设施模块保持贫血（逻辑稳定、变更少）
- 演进策略：在贫血模型基础上，先提取领域服务（Domain Service）封装跨实体逻辑；再将部分高频、强约束逻辑下沉到 Entity/ValueObject；最后通过重构消除冗余的 setter 和状态裸露
选择前先问三个问题
不用纠结“应该用哪个”，而是看当前上下文是否满足以下条件：
- 这个模块的业务规则是否经常被不同用例复用？→ 是，倾向充血
- 这个对象的状态是否有多处来源修改（前端表单、后台任务、第三方回调）？→ 是，贫血更易管控副作用
- 团队能否接受“new Order(...).confirm()" 这样的调用，而不是 "orderService.confirm(orderId)"？→ 否，暂缓充血
不复杂但容易忽略：模型选择本质是团队对业务理解程度的外化。先写清楚用例，再画状态图，最后决定数据怎么放、逻辑往哪走——比争论“贫血还是充血”有用得多。
