JAVA面试宝典 -《DDD实战：从贫血模型到领域事件》

DDD实战：从贫血模型到领域事件

引言：为什么从三层架构转向DDD？

在传统的三层架构中，我们习惯将系统划分为 Controller、Service 和 Repository 层，关注点更多落在“技术职责”而非“业务语义”。然而，随着系统复杂度提高，贫血模型、重复逻辑、脆弱耦合等问题层出不穷。
领域驱动设计（DDD） 正是为了解决这些问题而生。它强调以业务为中心建模，将“业务行为”作为核心驱动软件设计，帮助系统在演进中保持稳定性与可维护性。
本文通过电商案例，揭示如何从贫血模型迁移到富领域模型，并实现领域事件驱动架构。

1️⃣ 贫血模型的痛点

// 典型贫血模型示例
public class Order {
    private Long id;
    private String status;
    private BigDecimal amount;
    // 仅有getter/setter，无业务行为
}

@Service
public class OrderService {
    @Transactional
    public void payOrder(Long orderId) {
        Order order = orderRepository.findById(orderId);
        // 核心业务逻辑分散在Service层
        if (!"CREATED".equals(order.getStatus())) {
            throw new IllegalStateException("订单状态异常");
        }
        Payment payment = paymentClient.pay(order.getAmount());
        order.setStatus("PAID");
        orderRepository.save(order);  // 仅仅是数据更新
    }
}

痛点总结​​：

1. 业务规则散落在Service层，领域对象成为​​数据容器​​​​
2. 代码重复率高，修改成本随业务复杂度​​​​指数级上升​​​​
3. ​​​​技术实现侵蚀业务表达​​​​，难以体现领域概念

DDD的核心价值

✅ ​​统一语言​​：业务与开发共享领域模型词汇
✅ ​​边界控制​​：通过聚合划分业务一致性边界
✅ ​​领域聚焦​​：业务规则内聚在领域对象中

埃里克·埃文斯在《领域驱动设计》中强调：​​"模型是系统的核心"​​，贫血模型背离了这一基本原则

2️⃣ 聚合与聚合根：建模原则与实践

聚合设计关键原则

外部聚合

外部聚合

订单聚合根

订单项1

订单项2

支付

库存

核心规则​​：

1. ​​唯一入口​​​​：外部只能通过聚合根操作内部对象 ​​
2. ​​强一致性边界​​​​：聚合内修改满足业务规则 ​​
3. ​​设计要点​​​​：
   • 通过业务不变性规则划界（如：订单总额=所有订单项小计之和）
   • 聚合根负责维护内部对象的完整状态
   • 聚合间通过ID引用而非对象引用

避免“万物皆聚合根”

​​​​典型误用场景​​​​：

• 将数据库实体1:1映射为聚合根
• 将领域服务错标为聚合根
• 跨越限界上下文强行建立聚合根关系

​​​​​​修正方案​​​​​​：

// 订单聚合根示例
public class Order extends AbstractAggregateRoot<Order> {
    private OrderId id;
    private Money totalAmount;
    private List<OrderItem> items = new ArrayList<>();
    private OrderStatus status;

    // 业务方法封装在聚合根中
    public void addItem(Product product, int quantity) {
        // 业务规则内聚
        if (this.status != OrderStatus.CREATED) {
            throw new DomainException("订单状态异常");
        }
        
        OrderItem item = new OrderItem(product, quantity);
        this.items.add(item);
        this.totalAmount = this.totalAmount.add(item.getSubTotal());
    }

    // 事件触发点
    public void pay() {
        this.status = OrderStatus.PAID;
        registerEvent(new OrderPaidEvent(this.id));
    }
}

// 订单项作为内部实体（非聚合根）
public class OrderItem {
    private ProductId productId;
    private int quantity;
    private Money price;
}

​​陷阱提示​​：大聚合（如用户聚合包含订单历史）会导致​​并发冲突​​和​​性能问题​​，需按业务变化频率拆分

3️⃣ 领域服务 vs 应用服务：职责边界与代码演进

职责分工：

类型	职责
应用服务	协调多个聚合根、处理事务、DTO 转换、权限控制等
领域服务	封装跨聚合的业务逻辑，避免逻辑污染实体或聚合根

Java代码对比

​​领域服务示例​​：

public class OrderCalculationService {
    // 封装复杂价格计算策略（领域服务）
    public Money calculateTotal(List<OrderItem> items, DiscountPolicy policy) {
        Money total = items.stream()
            .map(OrderItem::getSubTotal)
            .reduce(Money.ZERO, Money::add);
        return policy.applyDiscount(total);
    }
}

应用服务示例​​：

@Service
@RequiredArgsConstructor
public class OrderAppService {
    private final OrderRepository orderRepository;
    private final PaymentClient paymentClient;  // 外部依赖
    private final DomainEventPublisher publisher;

    @Transactional
    public void payOrder(OrderId orderId) {
        Order order = orderRepository.findById(orderId);
        order.pay();  // 调用领域行为
        
        // 基础设施调用
        PaymentResponse response = paymentClient.execute(order.getTotal());
        order.confirmPayment(response);
        
        orderRepository.save(order);
        publisher.publishEvents(order);  // 发布领域事件
    }
}

演进建议

1. 初期可合并服务，复杂度上升后分离
2. ​​领域服务应是无状态​​的 ​​，仅依赖其他领域对象
3. 应用服务 ​​​​不处理​​ ​​业务规则，只做流程编排

4️⃣ CQRS 架构落地：读写分离与事件总线实战

⚡️架构原理图

命令

查询

事件消费

客户端

命令端

查询端

命令模型

领域事件

读模型

❌Spring Boot + Axon Framework实现

// 命令模型（写）
@Aggregate
public class OrderAggregate {
    @AggregateIdentifier
    private OrderId id;
    
    @CommandHandler
    public OrderAggregate(CreateOrderCommand command) {
        apply(new OrderCreatedEvent(command.getOrderId()));
    }
    
    @EventSourcingHandler
    public void on(OrderCreatedEvent event) {
        this.id = event.getOrderId();
    }
}

// 查询模型（读）
@Component
public class OrderProjection {
    private final OrderViewRepository repository;
    
    @EventHandler
    public void on(OrderCreatedEvent event) {
        repository.save(new OrderView(event.getOrderId()));
    }
}

// 最终一致性实现（事件传播）
@Configuration
public class EventConfig {
    @Bean
    public EventStorageEngine storageEngine(DataSource dataSource) {
        return JdbcEventStorageEngine.builder()
            .dataSource(dataSource)
            .build();
    }
}

✅异步事件处理

@Component
@ProcessingGroup("payment")
public class PaymentHandler {
    @EventHandler
    public void handle(OrderPaidEvent event) {
        // 调用支付外部系统（非阻塞）
        paymentClient.confirm(event.getOrderId());
    }
    
    // 事件重试策略
    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 1000))
    public void handlePaymentFailure() {...}
}

优势对比​​：

1. 写模型：保证核心领域强一致性
2. 读模型：独立优化查询性能（如物化视图）
3. 事件驱动：实现聚合间最终一致性

5️⃣ 事件风暴工作坊：从白板到建模的过程与工具

实操流程

准备阶段

识别领域事件

识别命令

识别聚合

划分限界上下文

建立流程

Miro工具建模示例

​​关键产出物​​：

1. ​​领域事件​​​​：订单已创建、付款已确认、库存已扣减 ​​
2. ​​命令​​​​：创建订单命令、支付订单命令
3. ​​​​聚合​​​​：Order、Payment、Inventory ​​
4. ​​策略​​​​：超时取消策略、折扣计算策略

✅​​​​团队协作技巧​​：

1. 邀请业务专家参与，用不同颜色便签区分类别
2. 优先识别核心域（Core Domain）
3. 对争议点进行边界上下文切分

6️⃣ 防腐层设计：保护核心领域免受外部侵蚀

架构设计

核心领域

防腐层

外部系统

DTO转换器

适配器

支付系统集成实现

// 防腐层接口（领域定义）
public interface PaymentProvider {
    PaymentResponse process(PaymentCommand command);
}

// 适配器实现（基础设施层）
@Primary
public class AlipayAdapter implements PaymentProvider {
    private final AlipayClient client;
    
    public PaymentResponse process(PaymentCommand command) {
        // 将领域命令转为外部系统DTO
        AlipayRequest request = convert(command);
        AlipayResponse response = client.execute(request);
        // 将外部响应转为领域对象
        return convert(response);
    }
}

// 领域内使用方法
@Service
@RequiredArgsConstructor
public class PaymentService {
    private final PaymentProvider provider;  // 依赖抽象
    
    public void executePayment(Order order) {
        PaymentCommand command = createCommand(order);
        PaymentResponse response = provider.process(command);
        order.handlePayment(response);  // 领域行为
    }
}

设计要点​​：

1. ​​依赖倒置​​​​：领域层只依赖防腐层接口 ​​
2. ​​双向转换​​​​：避免核心领域对象暴露给外部系统 ​​
3. ​​故障隔离​​​​：添加熔断器和超时控制

总结：DDD 落地的关键挑战与建议路径

演进路线建议

1. ​​明确核心域​​：事件风暴识别高价值领域 ​​
2. 渐进式改造​​： ​​
   • 第一步：建立聚合根，清除setter方法
   • 第二步：拆分领域/应用服务，引入领域事件
   • 第三步：按需实施CQRS
3. 持续重构​​：根据业务变化调整聚合边界

常见陷阱规避

⚠️ ​​聚合设计过大​​：导致并发冲突
✅ 解方：根据业务变更频率拆分聚合

⚠️ ​​事件风暴脱离业务​​：成为纯技术讨论
✅ 解方：强制业务方参与工作坊

⚠️ ​​过度设计防腐层​​：引入不必要复杂度
✅ 解方：仅在对接易变/不兼容系统时使用

正如Vernon在《实现领域驱动设计》中所说：​​“好的设计是在过度设计与设计不足之间取得平衡的艺术”​​

配套工具推荐

​​建模工具​​：

• Miro：事件风暴协作
• PlantUML：领域模型制图

​​开发框架​​：

• Spring Boot + Spring Data
• Axon Framework（CQRS支持）
• Jacoco（聚合根测试覆盖率）

学习资源​​：

• 《领域驱动设计精粹》：实践技巧速查
• DDD Crew官方GitHub：案例库