领域建模实践：解密贫血模型（Anemic Model）与充血模型（Rich Model）的本质对立

在主流的企业级 Java 开发中，开发人员习惯了使用传统的“三层架构”（Controller-Service-DAO）。在这种传统的开发模式中，所谓的领域实体（如 User、Order）通常只包含私有属性以及一堆自动生成的 Getter 和 Setter 方法，没有任何实质性的业务逻辑。所有的业务逻辑、校验规则都被塞进了臃肿的 Service 类中。

这种**“数据与行为分离”**的建模方案，在领域驱动设计（DDD）中被称为**贫血模型（Anemic Domain Model）**。而 DDD 所极力推崇的是将数据和紧密关联的行为强内聚在一起的**充血模型（Rich Domain Model）**。

本文将系统拆解贫血模型与充血模型的概念边界、面向对象设计差异以及充血模型的工程落地实践。

一、 核心范式对比：贫血模型 vs. 充血模型

我们通过多维指标对比直观呈现两种建模思想的对立本质：

二、 数据与行为的物理流转关系对比

我们通过物理调用拓扑清晰呈现两种开发范式的流量流转差异：

1. 贫血模型调用流

[ 客户端 ] ──> [ Service 业务包 ]
                    │  (Service 读取 Entity 属性, 在 Service 内部计算, 再 set 回去)
                    ├─ [ Entity (纯属性 DTO) ]
                    │
                    ▼
           [ DAO / Repository 保存 ]

2. 充血模型调用流

[ 客户端 ] ──> [ Service 编排包 ]
                    │  (Service 从 Repo 读取聚合根，直接调用聚合根的行为方法)
                    ▼
           [ 聚合根.executeBusiness() (内存完成状态修改与不变性保护) ]
                    │
                    ▼
           [ Repository.save(聚合根) ]

三、 代码实战：在基础设施层落地充血聚合设计

以下是一个严格符合 DDD 规范的“账户余额（Account）”充血聚合设计，强制捍卫“账户余额不能为负数”的不变性约束：

package com.company.domain.aggregate;

import java.math.BigDecimal;

/**
 * 账户聚合根：充血模型实现
 */
public class Account {
    private final String accountId;
    private BigDecimal balance; // 余额封闭，杜绝 Setter 暴露给外部

    public Account(String accountId, BigDecimal initialBalance) {
        if (initialBalance.compareTo(BigDecimal.ZERO) < 0) {
            throw new IllegalArgumentException("初始余额不能为负数！");
        }
        this.accountId = accountId;
        this.balance = initialBalance;
    }

    /**
     * 业务行为：扣款（内置不变性守卫）
     */
    public void withdraw(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("扣款金额必须大于零！");
        }
        
        // 执行核心不变性校验
        BigDecimal newBalance = this.balance.subtract(amount);
        if (newBalance.compareTo(BigDecimal.ZERO) < 0) {
            throw new IllegalStateException("账户余额不足，扣款失败！");
        }
        
        this.balance = newBalance; // 状态安全更新
    }

    public String getAccountId() { return accountId; }
    public BigDecimal getBalance() { return balance; }
}

四、 总结

贫血模型与充血模型的博弈，不仅是 DDD 战术设计的选择，更是面向对象程序设计范式的本源复归。

它通过**坚决取缔失血的 Setter 通道，将数据状态更新与核心业务校验紧紧包裹于聚合根的领域动作中，从底层消除了“数据脏变”的安全隐患**；并通过**将过程业务逻辑封装为可复用的内聚对象，让软件模型天然对应真实的商业概念**。掌握这套充血实体设计与工程整合红线，是重构失控的面条 Service 代码、防范软件系统熵增演进的核心看家本领！