领域驱动设计：贫血模型与充血模型实战解析

1. 贫血模型与充血模型的本质区别

我第一次接触领域驱动设计（DDD）时，对贫血模型和充血模型的概念感到困惑。直到在实际项目中踩过几次坑后，才真正理解它们的差异。贫血模型就像一具没有灵魂的躯壳，而充血模型则是充满活力的有机体。

贫血模型中，对象仅仅是数据的容器，所有业务逻辑都集中在Service层。这种模式在Spring应用中非常常见，比如典型的User类只有getter/setter，而UserService则包含所有业务方法。这种设计的问题在于，它违反了面向对象的基本原则——数据和行为的封装。

充血模型则完全不同。它要求将业务逻辑尽可能地放在领域对象内部。以订单系统为例，在充血模型中，Order类不仅包含订单数据，还包含addItem()、calculateTotal()等业务方法。这种设计更符合"高内聚、低耦合"的原则。

关键区别：贫血模型的对象是被动的数据载体，充血模型的对象是主动的业务实体。这种差异直接影响代码的可维护性和扩展性。

2. 为什么Spring项目容易陷入贫血模型陷阱

Spring框架的设计哲学某种程度上助长了贫血模型的流行。默认的Controller-Service-Repository分层架构，很容易让人不假思索地把所有业务逻辑都塞进Service层。

我参与过的一个电商项目就是典型案例。初期为了快速开发，团队采用了典型的贫血模型：Product类只有字段定义，所有业务逻辑都在ProductService中。随着需求增加，这个Service类膨胀到了3000多行代码，维护变得极其困难。

另一个常见原因是ORM工具的使用方式。JPA和MyBatis等工具默认生成的实体类都是贫血的，开发者很容易延续这种模式。我曾见过一个团队为了"保持一致性"，硬是把本应放在领域对象中的验证逻辑抽到了Service层。

实战经验：Spring并不强制使用贫血模型，但它的默认配置和常见示例确实会引导开发者朝这个方向走。有意识地抵抗这种惯性很重要。

3. 充血模型在Spring中的实现策略

将充血模型引入Spring项目需要一些技巧。首先要在领域对象中注入必要的依赖。Spring官方推荐的方式是通过方法注入而非字段注入：

java复制@Entity
public class Order {
    @Transient
    private DiscountCalculator discountCalculator;
    
    public void setDiscountCalculator(DiscountCalculator calculator) {
        this.discountCalculator = calculator;
    }
    
    public void applyDiscount() {
        // 使用discountCalculator执行业务逻辑
    }
}

在Service层，我们可以这样使用充血对