• • 贫血模型：对象只有数据（字段 + getter/setter），没有行为。业务逻辑全写在 Service 里。对象是个"数据袋子"。
• • 充血模型：对象既有数据，也有操作这些数据的行为（业务方法）。业务逻辑写在对象自己身上。对象是个"会干活的人"。

类比：

　　贫血 = 一份病历表（只记录数据）+ 一个医生（Service，所有诊断治疗都他干）。病历自己什么都不会。

　　充血 = 一个真实的病人，他自己会发烧、会康复、会对药物产生反应。行为长在他身上。

贫血模型弊端：

• 1. 规则没人守。order.setStatus(5) 这行代码，任何地方都能调。哪天有个同事在别处写 order.setStatus(5) 而忘了检查"是否已发货"，就把已发货订单取消了，数据直接出错。Order 自己毫无防御能力。
• 2. 规则会重复和漂移。"已发货不能取消"这条规则，取消接口写一遍、批量取消又写一遍、定时任务再写一遍，迟早不一致。
• 3. 魔法数字满天飞。status == 3、setStatus(5)，可读性极差，违背统一语言。
• 4. 对象和行为分离，违反面向对象的封装原则。数据在 Order，操作数据的逻辑却在 OrderService，谈不上"对象"。

充血模型好处：

• 1. 规则只有一个守门人。想取消订单？只能调 order.cancel()，而它内部强制检查规则。没有 setStatus，外部根本没法跳过检查直接改状态。规则无处可逃。
• 2. 规则只写一处。无论从哪取消订单，都走 order.cancel()，规则天然统一。
• 3. 代码即业务。order.cancel()、order.pay() 直接对应业务语言（统一语言落地），自解释。
• 4. 真正的面向对象：数据和操作数据的行为封装在一起。

为什么 DDD 推崇充血模型

一句话：充血模型让"业务规则"有了一个明确、唯一、无法绕过的家。

贫血模型的本质问题是——它把"数据"和"操作数据的规则"拆开了。规则一旦离开数据独自待在 Service 里，就失去了对数据的守护能力，谁都能绕过它直接 setXxx。系统一大，规则就会被无数个 Service 方法重复实现、各自漂移，最终腐烂成大泥球。

充血模型把规则塞回数据旁边，让对象自己守护自己的不变式（呼应第 06 章聚合根）。这是 DDD 战术设计的灵魂。