贫血模型将数据与业务逻辑分离，model仅作数据容器，service承担全部逻辑；充血模型则让领域对象封装自身状态与行为，如user.activate()，service退为协调者。
面向对象系统设计中，贫血模型和充血模型不是“对错”之分，而是业务复杂度、团队能力与演进节奏共同决定的变量分配策略。关键不在“用哪个”，而在“数据和行为该由谁承担、何时移交、边界在哪”。
贫血模型：适合快速交付、逻辑轻、变更频的场景
它把数据（如 UserEntity、OrderDTO）和行为（如 UserService.activate()、OrderService.calculateDiscount()）彻底分离。Model 只是容器，Service 承担全部业务判断与流程控制。
- 优点：结构清晰，各层职责分明；Controller → Service → Repository 链路直白，新人上手快；ORM 映射友好，数据库驱动开发顺滑
- 适用情况：MVP 验证期项目、运营活动后台、内部工具系统、CRUD 主导型接口（如配置管理、审批流基础节点）
- 风险提示：当订单出现自营/入驻/分销多类型时，Service 层容易堆积 if-else 或策略工厂，BO 类膨胀但无行为，领域语义丢失；新增子类型需同步改实体、服务、编排层，违反开闭原则
充血模型：适合核心域稳定、逻辑重、需长期演进的系统
它让领域对象自己说话——User.activate()、Order.confirm()、Account.withdraw() 这些方法直接定义在对象内部，Service 退为协调者，只负责加载、调用、保存。
- 优点：业务逻辑内聚，状态变更受控（如 activate() 内自动校验+设状态+发事件）；修改局部化，改一个方法即可覆盖所有调用点；回归测试范围小，领域语言与代码一致，方便和产品、业务对齐
- 适用情况：支付清结算、风控引擎、供应链主干、会员成长体系等核心业务平台；团队已具备 DDD 基础或有领域专家深度参与
- 注意点：不能把所有逻辑都塞进 Domain 对象——事务边界、跨聚合操作、第三方调用（如发短信、调账务）仍应留在 Application Service；避免“肥模型”，比如让 User 承担发邮件、查积分、调物流等不相关职责
变量分配的实操判断清单
面对一个新模块或重构任务，可快速过一遍以下问题：
- 这个对象的状态是否有多套约束规则？（例如：订单只能从“待支付”转“已支付”，不能跳过）→ 倾向充血
- 它的行为是否高度复用且与自身数据强绑定？（例如：账户余额 = 上期余额 + 入账 - 出账）→ 倾向充血
- 当前团队是否常因“改一个字段要动三个类”而返工？→ 贫血模型可能已到维护临界点
- 未来半年是否有明确的领域扩展计划（如新增订单类型、账户子类）？→ 充血模型+继承/策略组合更利于演进
- 系统是否重度依赖 SQL 编写，且多数逻辑藏在 WHERE 和 JOIN 里？→ 立即上充血模型成本高，建议先做“半充血”过渡（如在 BO 中加 validate()、toDto() 等轻量行为）
混合落地更常见：别卡在非黑即白
真实项目很少纯贫或纯充。更务实的做法是分层混合：
- 核心聚合根（如 Order、Policy）用充血，封装生命周期与不变规则
- 查询类对象（如 DashboardSummary、ReportItem）保持贫血，专注数据组装
- DTO/VO/Entity 始终贫血——它们本就不该承载业务逻辑
- Service 层保留“编排权”：跨聚合调用、事务控制、防腐层适配、最终一致性保障
模型选型本质是责任切分的艺术。贫血让分工显性化，充血让语义显性化。选哪个，取决于你此刻最想降低哪类成本：是开发速度、协作理解，还是长期维护熵值。
