领域驱动设计：贫血模型与充血模型的本质与实践

1. 领域驱动设计中的模型之争：贫血与充血本质解析

第一次接触领域驱动设计(DDD)时，我被各种模型概念搞得晕头转向。直到在电商订单系统重构中踩了坑才明白：模型选择直接决定代码是越写越顺还是越改越乱。贫血模型(Anemic Model)和充血模型(Rich Model)这对看似简单的概念，实则是架构设计的分水岭。

1.1 贫血模型的典型特征

典型的贫血模型代码是这样的：

java复制// 订单服务
public class OrderService {
    public void createOrder(OrderDTO dto) {
        Order order = new Order();
        order.setId(UUID.randomUUID());
        order.setItems(dto.getItems());
        // 十余行setter调用...
        orderRepository.save(order);
    }
    
    public void cancelOrder(Long orderId) {
        Order order = orderRepository.findById(orderId);
        order.setStatus(CANCELLED);
        orderRepository.save(order);
    }
}

// 订单实体
public class Order {
    private Long id;
    private List<Item> items;
    private OrderStatus status;
    // 只有getter/setter
}

这种模式的问题在于：

• 业务逻辑全部集中在Service层，实体沦为数据容器
• 修改业务规则需要跨多个Service类追踪
• 单元测试必须依赖Service完整上下文

我在物流系统中就遇到过：运费计算逻辑分散在5个Service类中，每次调整运费策略都要做全局影响分析。

1.2 充血模型的实现要点

改造后的充血模型版本：

java复制public class Order {
    private Long id;
    private List<Item> items;
    private OrderStatus status;
    
    public static Order create(List<Item> items) {
        validateItems(items);
        Order order = new Order();
        order.id = UUID.randomUUID();
        order.items = Collections.unmodifiableList(items);
        order.status = CREATED;
        DomainEventPublisher.publish(new OrderCreatedEvent(order));
        return order;
    }
    
    public void cancel() {
        if (!isCancellable()) {
            throw new IllegalStateException("订单当前状态不可取消");
        }
        this.status = CANCELLED;
        DomainEventPublisher.publish(new OrderCancelledEvent(this));
    }
    
    private static void validateItems(List<Item> items) {
        // 校验逻辑...
    }
}

关键转变在于：

• 实体不再只是数据容器，而是业务行为的载体
• 领域对象保持自洽性，对外提供行为方法而非属性操作
• 业务规则内聚在对象内部，变化时只需修改单一类

1.3 模型选择的决策矩阵

根据三个项目实践经验，我总结的决策依据：

特别提醒：在金融交易系统中采用贫血模型后，我们不得不用2000行的TransactionService来处理所有业务规则，而改用充血模型后，业务逻辑被合理分配到Account、Transaction等领域对象中，维护效率提升40%。

2. Spring生态下的充血模型落地实践

在Spring框架中实现充血模型需要突破一些常规用法。去年重构供应链系统时，我们成功将80%的业务逻辑从Service层迁移到领域模型，以下是关键实践。

2.1 依赖注入的变通方案

传统Spring开发习惯在Service中注入Repository，但在充血模型中：

java复制public class Warehouse {
    private InventoryRepository repository; // 不直接注入
    
    public void adjustInventory(Item item, int delta) {
        // 通过方法参数传入依赖
        Inventory inventory = repository.findByItem(item);
        inventory.adjust(delta);
    }
}

// 配置类
@Configuration
public class DomainConfig {
    @Bean
    public Warehouse warehouse(InventoryRepository repo) {
        Warehouse warehouse = new Warehouse();
        warehouse.setRepository(repo); // 构造期注入
        return warehouse;
    }
}

重要提示：避免在领域对象中使用@Autowired，这会导致：

1. 测试时需要加载完整Spring上下文
2. 对象序列化时可能遇到代理问题
3. 破坏领域模型的纯粹性

2.2 事务管理的特殊处理

充血模型中事务边界需要重新设计：

java复制public class OrderService {
    private final OrderRepository orderRepo;
    private final PaymentGateway paymentGateway;
    
    @Transactional
    public void completeOrder(Long orderId) {
        Order order = orderRepo.findById(orderId);
        order.complete(); // 内部可能包含支付操作
        orderRepo.save(order);
    }
}

public class Order {
    private PaymentGateway gateway; // 接口依赖
    
    public void complete() {
        if (this.status != PAID) {
            gateway.charge(this); // 领域行为
        }
        this.status = COMPLETED;
    }
}

我们采用的实践方案：

1. 在Service方法上声明@Transactional
2. 领域对象通过接口依赖外部服务
3. 使用依赖倒置原则(DIP)解耦具体实现

2.3 Spring Data整合技巧

与JPA一起使用时需注意：

java复制@Entity
public class Product {
    @Id private Long id;
    private String name;
    
    @Transient // 标记非持久化字段
    private PricingStrategy strategy;
    
    public Money calculatePrice() {
        return strategy.apply(this);
    }
    
    @PostLoad
    private void initialize() {
        this.strategy = PricingStrategyFactory.get(name);
    }
}

踩坑记录：

• 避免在实体构造函数中初始化复杂逻辑，JPA会通过反射创建实例
• 使用@PostLoad回调进行后期初始化
• @Transient字段要确保不参与equals/hashCode计算

3. 复杂业务场景下的模型演进

在保险理赔系统中，我们经历了从贫血模型到充血模型的渐进式改造，以下是关键转折点。

3.1 状态机模式的实现对比

贫血模型实现：

java复制public class ClaimService {
    public void processClaim(Long claimId) {
        Claim claim = claimRepo.findById(claimId);
        if (claim.getStatus() == SUBMITTED) {
            claim.setStatus(UNDER_REVIEW);
            claimRepo.save(claim);
            reviewService.startReview(claim);
        } else if (...) {
            // 更多条件分支...
        }
    }
}

充血模型改进：

java复制public class Claim {
    private ClaimState state = new SubmittedState();
    
    public void process() {
        state.handle(this);
    }
    
    interface ClaimState {
        void handle(Claim context);
    }
    
    class UnderReviewState implements ClaimState {
        void handle(Claim context) {
            reviewService.startReview(context);
            context.setState(new ReviewedState());
        }
    }
}

改造后的优势：

• 状态转换逻辑内聚在领域对象中
• 新增状态只需添加新实现类
• 单元测试可以针对每个状态单独验证

3.2 领域事件的应用实践

在订单履约系统中，我们采用领域事件解耦流程：

java复制public class Order {
    public void fulfill() {
        if (this.items.stream().anyMatch(Item::isBackordered)) {
            this.status = PARTIALLY_FULFILLED;
            DomainEventPublisher.publish(
                new OrderPartiallyFulfilledEvent(this));
        } else {
            this.status = FULFILLED;
            DomainEventPublisher.publish(
                new OrderFulfilledEvent(this));
        }
    }
}

// 事件处理器
@Component
public class InventoryHandler {
    @EventListener
    public void handle(OrderFulfilledEvent event) {
        inventoryService.adjustStock(event.getItems());
    }
}

实施要点：

1. 使用Spring的@EventListener简化事件处理
2. 领域对象不直接依赖事件发布实现
3. 事件应携带最小必要数据，避免序列化问题

3.3 聚合根的设计陷阱

在电商平台重构时，我们曾错误地将Customer作为包含所有Order的聚合根，导致：

• 加载客户信息时连带加载上千条订单
• 订单操作需要全局锁

改进后的设计：

java复制public class Customer {
    private CustomerId id;
    // 基本属性...
}

public class Order {
    private OrderId id;
    private CustomerId customerId; // 引用而非包含
}

聚合设计原则：

1. 通过ID引用而非对象引用
2. 聚合边界应围绕真正需要强一致性的业务概念
3. 单个聚合尽量不超过100个属性或10个集合

4. 性能优化与疑难解决方案

在日订单量百万级的系统中，充血模型的性能优化至关重要。以下是经过实战验证的方案。

4.1 延迟加载的平衡艺术

错误示范：

java复制public class Order {
    @OneToMany(fetch = FetchType.EAGER)
    private List<OrderLine> lines;
    
    public BigDecimal getTotal() {
        return lines.stream()
            .map(OrderLine::getSubtotal)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
}

改进方案：

java复制public class Order {
    @OneToMany(fetch = FetchType.LAZY)
    private List<OrderLine> lines;
    
    public BigDecimal getTotal() {
        // 通过Repository按需加载
        return orderLineRepo.findByOrder(this).stream()
            .map(OrderLine::getSubtotal)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
}

性能对比数据：

4.2 并发控制的实现策略

库存扣减的典型问题：

java复制public class Product {
    private int stock;
    
    public void deductStock(int quantity) {
        if (this.stock < quantity) {
            throw new InsufficientStockException();
        }
        this.stock -= quantity; // 并发情况下会超卖
    }
}

解决方案对比：

1. 乐观锁方案：

java复制@Entity
public class Product {
    @Version
    private Long version;
    
    public void deductStock(int quantity) {
        // JPA会自动检测版本冲突
    }
}

2. 悲观锁方案：

java复制public class InventoryService {
    @Transactional
    public void deductWithLock(Long productId, int quantity) {
        Product product = productRepo.findWithLock(productId);
        product.deductStock(quantity);
    }
}

3. 领域特定方案：

java复制public class Product {
    public void deductStock(int quantity, InventoryReservationRepo repo) {
        repo.reserve(this, quantity); // 使用预留库存模式
    }
}

4.3 复杂查询的处理之道

充血模型中如何处理报表查询：

java复制public class OrderReportService {
    public OrderStats getStats(LocalDate from, LocalDate to) {
        // 使用专门的查询模型
        return orderQueryRepo.findStats(from, to);
    }
}

// 查询专用Repository
public interface OrderQueryRepository {
    @Query("SELECT new com...OrderStats(...) FROM ...")
    OrderStats findStats(@Param("from") LocalDate from, 
                        @Param("to") LocalDate to);
}

关键原则：

1. 命令查询职责分离(CQRS)
2. 为读操作设计专用模型
3. 必要时使用原生SQL优化查询

5. 测试策略的调整与优化

充血模型改变了传统Spring应用的测试方式。在持续交付流水线中，我们建立了新的测试规范。

5.1 单元测试的蜕变

贫血模型的测试：

java复制class OrderServiceTest {
    @Mock OrderRepository repo;
    
    @Test
    void shouldCancelOrder() {
        OrderService service = new OrderService(repo);
        Order order = new Order();
        when(repo.findById(1L)).thenReturn(order);
        
        service.cancelOrder(1L);
        
        assertThat(order.getStatus()).isEqualTo(CANCELLED);
    }
}

充血模型的测试：

java复制class OrderTest {
    @Test
    void shouldRejectCancellationWhenShipped() {
        Order order = new Order();
        order.ship();
        
        assertThatThrownBy(order::cancel)
            .isInstanceOf(IllegalStateException.class)
            .hasMessageContaining("已发货订单不可取消");
    }
}

测试覆盖率提升：

• 业务规则覆盖率从65%提升至92%
• 测试执行时间从8分钟缩短到90秒
• 模拟对象使用减少70%

5.2 集成测试的调整

新的测试结构：

java复制@SpringBootTest
class OrderIntegrationTest {
    @Autowired OrderRepository repo;
    
    @Test
    @Transactional
    void shouldPersistDomainEvents() {
        Order order = Order.create(...);
        repo.save(order);
        
        order.fulfill();
        repo.save(order);
        
        assertThat(eventCaptor.getAllValues())
            .hasSize(1)
            .first().isInstanceOf(OrderFulfilledEvent.class);
    }
}

测试金字塔调整：

code复制        [传统]          [新模型]
       UI Tests        UI Tests
      /       \        /     \
 Service Tests  |     API Tests  |
     \       /        \     /
   Unit Tests      Domain Tests

5.3 测试数据构建的进化

使用Test Data Builder模式：

java复制class OrderBuilder {
    private List<Item> items = List.of(
        new ItemBuilder().withProduct("p1").build());
    
    public OrderBuilder withHighValueItem() {
        this.items = List.of(
            new ItemBuilder().withPrice(10000).build());
        return this;
    }
    
    public Order build() {
        return Order.create(items);
    }
}

@Test
void shouldRequireApprovalForHighValueOrder() {
    Order order = new OrderBuilder()
        .withHighValueItem()
        .build();
    
    assertThat(order.requiresApproval()).isTrue();
}

构建器模式的优势：

1. 避免测试代码中的重复构造逻辑
2. 显式表达测试用例的关键特征
3. 易于扩展新的构建场景