复杂的业务，事件风暴驱动DDD也许是良好的解决方案

在微服务架构大行其道的今天，如何有效处理复杂业务系统的领域边界划分始终是一个难题。

事件风暴作为领域驱动设计(DDD)中的一项核心实践，它通过业务部门、产品、开发等多方协作的工作坊形式，帮助团队厘清业务流程、统一认知，从而更好地指导微服务架构设计。

1. 事件风暴的本质认知

传统的需求分析往往陷入细节泥潭，而事件风暴则转换视角，以业务事件为核心，构建起完整的业务场景图景。

1.1 核心要素

• • 领域事件：用橙色便签表示，采用"过去时"描述，如"订单已支付"

• • 命令：用蓝色便签表示，触发事件的操作，如"提交订单"

• • 外部系统：用紫色便签表示，与当前系统存在交互的外部依赖

• • 聚合根：用黄色便签表示，用于组织和管理一组相关实体

• • 策略/规则：用绿色便签表示，描述重要的业务规则与约束

2. 事件风暴工作坊实践精要

2.1 前期准备

• • 参与人员：产品负责人、领域专家、架构师、核心开发

• • 物料准备：大尺寸白板、不同颜色便签、马克笔

• • 时间安排：建议2-3天，每天6小时，保持专注

2.2 探索阶段

用一个订单场景举例：

1. 1. 收集领域事件："订单已创建"→"支付已完成"→"库存已锁定"→"订单已发货"

2. 2. 分析触发命令："提交订单"→"支付订单"→"确认发货"

3. 3. 识别外部系统：支付系统、库存系统、物流系统

4. 4. 讨论业务规则：库存不足时订单创建策略、订单超时关闭规则

3. 从事件风暴到领域模型

3.1 领域分割技巧

• • 业务行为内聚：将紧密关联的业务行为归入同一领域

• • 数据依赖分析：梳理实体间的数据依赖关系

• • 变更频率考量：变更频率相近的功能适合放在一起

举个案例：电商订单域的划分

订单域：
  - 聚合根：订单(Order)
  - 实体：订单项(OrderItem)、收货地址(ShippingAddress)
  - 值对象：商品快照(ProductSnapshot)、支付信息(PaymentInfo)

3.2 上下文映射

• • 合作关系(Partnership)：订单域与支付域

• • 防腐层(ACL)：订单域与外部物流系统

• • 开放主机服务(OHS)：订单域对外提供的API

• • 发布语言(Published Language)：统一的消息格式规范

4. 实现层面的考量

4.1 领域事件的异步处理

@DomainEvents
Collection<OrderEvent> domainEvents() {
    // 收集待发布的领域事件
    return Collections.unmodifiableCollection(events);
}

@Async
@EventListener
public void handleOrderPaidEvent(OrderPaidEvent event) {
    // 处理订单支付完成事件
    inventoryService.lockStock(event.getOrderId());
}

4.2 聚合根设计

@Aggregate
public class Order {
    @AggregateIdentifier
    private OrderId id;
    private OrderStatus status;
    private Money totalAmount;
    private List<OrderItem> items;

    @CommandHandler
    public Order(CreateOrderCommand cmd) {
        // 业务规则验证
        validateBusinessRules(cmd);
        
        // 应用领域事件
        apply(new OrderCreatedEvent(cmd.getOrderId(), cmd.getItems()));
    }
}

5. 注意事项与最佳实践

5.1 常见陷阱

• • 过度细化：不必追求完美，把握主要矛盾

• • 忽视约束：要充分考虑业务规则和技术约束

• • 角色缺失：确保关键角色参与，特别是领域专家

5.2 成功要素

• • 统一语言：建立领域通用语言词汇表

• • 持续演进：领域模型需要随业务变化不断调整

• • 团队共识：通过工作坊凝聚团队认知

通过事件风暴，我们不仅能够快速理清业务脉络，更重要的是能够建立起团队共同的业务认知，这正是DDD实践成功的关键所在。

6. 进阶：事件溯源

事件溯源是DDD的一种高级实践，它通过记录所有改变状态的领域事件来重建聚合根状态。

@EventSourcingHandler
public void on(OrderCreatedEvent event) {
    this.id = event.getOrderId();
    this.status = OrderStatus.CREATED;
    this.items = event.getOrderItems();
}

@EventSourcingHandler
public void on(OrderPaidEvent event) {
    this.status = OrderStatus.PAID;
    this.paymentInfo = event.getPaymentInfo();
}

这种方式特别适合需要审计、追溯和回滚能力的业务场景。

7. DDD战术设计模式精讲

7.1 值对象(Value Object)设计

值对象是领域驱动设计中一个常被误用的概念，让我们通过一个实际案例深入理解：

public class Money {
    private final BigDecimal amount;
    private final Currency currency;
    
    // 值对象特征：不可变性
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new CurrencyMismatchException();
        }
        return new Money(amount.add(other.amount), currency);
    }
    
    // 值对象特征：基于属性的相等性
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Money money = (Money) o;
        return amount.compareTo(money.amount) == 0 && 
               currency.equals(money.currency);
    }
}

7.2 聚合设计的进阶技巧

7.2.1 一致性边界控制

举个订单场景的聚合设计：

public class Order {
    private List<OrderItem> items;  // 订单项作为订单聚合的一部分
    private OrderStatus status;
    private Money totalAmount;
    
    public void addItem(Product product, int quantity) {
        // 业务规则验证
        validateProductAvailable(product);
        validateOrderEditable();
        
        // 确保聚合内一致性
        OrderItem item = new OrderItem(product, quantity);
        items.add(item);
        recalculateTotalAmount();
    }
    
    private void recalculateTotalAmount() {
        this.totalAmount = items.stream()
            .map(OrderItem::getSubtotal)
            .reduce(Money.ZERO, Money::add);
    }
}

7.3 领域服务的高级应用

当某个业务操作涉及多个聚合时，应该使用领域服务：

@DomainService
public class OrderProcessingService {
    @Transactional
    public void processOrder(Order order) {
        // 库存检查
        inventoryService.checkAndReserve(order.getItems());
        
        // 支付处理
        Payment payment = paymentService.process(order.getTotalAmount());
        
        // 订单状态更新
        order.markAsPaid(payment);
        
        // 发布领域事件
        eventPublisher.publish(new OrderProcessedEvent(order.getId()));
    }
}

8. 微服务架构与DDD的协奏

8.1 限界上下文映射模式

// 防腐层示例
@AntiCorruptionLayer
public class LogisticsServiceAdapter implements LogisticsService {
    private final ThirdPartyLogisticsApi api;
    
    @Override
    public ShipmentStatus translateStatus(String externalStatus) {
        // 将外部系统状态映射为我们的领域概念
        return switch (externalStatus) {
            case "SHIPPED" -> ShipmentStatus.IN_TRANSIT;
            case "DELIVERED" -> ShipmentStatus.DELIVERED;
            default -> ShipmentStatus.UNKNOWN;
        };
    }
}

8.2 分布式事务处理

基于DDD的事件驱动架构处理分布式事务：

@Saga
public class OrderFulfillmentSaga {
    @StartSaga
    @SagaEventHandler(associationProperty = "orderId")
    public void handle(OrderCreatedEvent event) {
        // 发送支付命令
        commandGateway.send(new ProcessPaymentCommand(event.getOrderId()));
    }
    
    @SagaEventHandler(associationProperty = "orderId")
    public void handle(PaymentCompletedEvent event) {
        // 发送库存锁定命令
        commandGateway.send(new ReserveInventoryCommand(event.getOrderId()));
    }
    
    @EndSaga
    @SagaEventHandler(associationProperty = "orderId")
    public void handle(InventoryReservedEvent event) {
        // Saga结束
        // 发送订单确认命令
        commandGateway.send(new ConfirmOrderCommand(event.getOrderId()));
    }
}

9. DDD实践的演进与优化

9.1 性能优化策略

9.1.1 聚合加载优化

@Repository
public class OrderRepository {
    // 针对不同场景的加载策略
    public Order findByIdWithItems(OrderId id) {
        return entityManager
            .createQuery("""
                SELECT o FROM Order o 
                LEFT JOIN FETCH o.items 
                WHERE o.id = :id
                """)
            .setParameter("id", id)
            .getSingleResult();
    }
    
    // 仅加载订单状态的轻量级查询
    public OrderStatus findOrderStatusById(OrderId id) {
        return entityManager
            .createQuery("""
                SELECT o.status FROM Order o 
                WHERE o.id = :id
                """)
            .setParameter("id", id)
            .getSingleResult();
    }
}

9.2 CQRS模式应用

将复杂查询与命令处理分离：

// 命令侧
@CommandHandler
public class OrderCommandHandler {
    public void handle(CreateOrderCommand cmd) {
        Order order = new Order(cmd.getOrderId(), cmd.getItems());
        repository.save(order);
    }
}

// 查询侧
@QueryHandler
public class OrderQueryHandler {
    public OrderSummaryDTO handle(GetOrderSummaryQuery query) {
        return orderReadRepository
            .findOrderSummaryById(query.getOrderId())
            .orElseThrow(() -> new OrderNotFoundException(query.getOrderId()));
    }
}

10. 总结与展望

DDD结合事件风暴不仅是一种设计方法，更是一种促进团队协作、统一认知的有效工具。

在文章最后添加以下参考资料段落：

参考资料

1. 1. Vernon V. (2023). Implementing Domain-Driven Design. Addison-Wesley Professional.
   这本书深入探讨了DDD的战术设计模式和实现策略

2. 2. Evans E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
   DDD的奠基之作，提出了核心概念和方法论

3. 3. Brandolini A. (2021). Event Storming: An act of Deliberate Collective Learning.
   事件风暴方法的创始人所著，详细阐述了工作坊的组织和引导技巧

END

往期推荐
轻松生成PDF—QuestPDF的终极解决方案
扔掉所有Nginx的书籍吧
从复杂到简单：颠覆你的 Redis 管理体验

传统Java开发已死？重新定义云原生时代的Java开发！
开源界的又一匹黑马：AppFlowy让你的笔记如虎添翼