一个 20 人的开发团队花了两个月画 UML 图和写需求文档，依然对核心业务流程的理解存在分歧。直到有一天，团队把领域专家、开发者、测试人员全部拉进一个大会议室，用橙色便利贴写出了系统中发生的所有事件——两个小时后，所有人第一次在同一幅图上看到了业务全貌。这就是事件风暴（Event Storming）的力量。

事件风暴是意大利软件架构师 Alberto Brandolini 在 2012 年提出的一种协作建模方法。它通过识别领域事件（Domain Event）来探索业务领域，并将发现逐步细化为可落地的软件设计。本文将完整介绍事件风暴的三个层次、领域事件的设计规范，以及从事件风暴到限界上下文和聚合的推导方法。

上一篇：DDD 战术模式 | 下一篇：防腐层与开放主机服务

一、什么是领域事件

1.1 定义

领域事件（Domain Event）是领域中发生的、具有业务意义的事实。它用过去时态命名，描述已经发生的事情。

命名规范：

正确：OrderPlaced, PaymentReceived, ShipmentDelivered
错误：PlaceOrder, ReceivePayment, DeliverShipment  ← 这是命令，不是事件

1.2 领域事件的特征

1.3 领域事件 vs 集成事件

在前一篇 DDD 战术模式 中已经简要提到这两者的区别，这里做进一步展开。

领域事件（Domain Event）是限界上下文内部的建模概念，表达聚合状态变迁的事实。集成事件（Integration Event）是跨限界上下文的通信机制，通常通过消息中间件传递。

graph LR
    subgraph "交易上下文"
        A["Order 聚合"] -->|"产生"| DE["领域事件<br/>OrderConfirmed"]
        DE -->|"转换"| IE["集成事件<br/>OrderConfirmedIntegration"]
    end

    IE -->|"消息队列"| subgraph2

    subgraph subgraph2 ["物流上下文"]
        ACL2["防腐层"] -->|"转换"| DE2["领域事件<br/>ShippingOrderCreated"]
        DE2 -->|"触发"| B["Shipment 聚合"]
    end

关键区别：

1.4 领域事件的代码结构

// 基础事件接口
public interface DomainEvent {
    Instant occurredAt();
    String eventType();
}

// 具体领域事件
public record OrderPlacedEvent(
    OrderId orderId,
    CustomerId customerId,
    List<OrderLineSnapshot> lines,
    Money totalAmount,
    Instant occurredAt
) implements DomainEvent {

    public OrderPlacedEvent {
        Objects.requireNonNull(orderId);
        Objects.requireNonNull(customerId);
        Objects.requireNonNull(lines);
        Objects.requireNonNull(totalAmount);
        if (occurredAt == null) {
            occurredAt = Instant.now();
        }
    }

    @Override
    public String eventType() {
        return "order.placed";
    }
}

// 集成事件——用于跨上下文传播
public record OrderPlacedIntegrationEvent(
    String orderId,
    String customerId,
    List<LineItemDto> items,
    String totalAmount,
    String currency,
    String occurredAt
) {
    // 从领域事件转换
    public static OrderPlacedIntegrationEvent from(OrderPlacedEvent domainEvent) {
        return new OrderPlacedIntegrationEvent(
            domainEvent.orderId().value(),
            domainEvent.customerId().value(),
            domainEvent.lines().stream()
                .map(l -> new LineItemDto(l.productId(), l.quantity(), l.price()))
                .toList(),
            domainEvent.totalAmount().amount().toPlainString(),
            domainEvent.totalAmount().currency().getCurrencyCode(),
            domainEvent.occurredAt().toString()
        );
    }
}

二、事件风暴概述

2.1 什么是事件风暴

事件风暴是一种基于便利贴的协作建模工作坊方法。其核心理念是：

1. 把所有相关角色（开发者、领域专家、产品经理、测试人员）聚集在一起；
2. 用不同颜色的便利贴表示不同类型的领域概念；
3. 在一面大墙上按时间线排列这些概念；
4. 通过讨论和迭代，逐步揭示业务全貌。

2.2 为什么需要事件风暴

传统的需求分析方法（用例图、流程图、需求文档）有几个共同的问题：

事件风暴通过同步协作解决了这些问题。所有人在同一时间、同一地点，对同一个模型进行讨论。

2.3 三个层次

事件风暴有三个递进的层次，每个层次解决不同的问题：

┌─────────────────────────────────────────────┐
│  层次三：软件设计（Software Design）          │
│  目标：定义聚合、命令处理器、读模型            │
│  参与者：开发者                               │
│  时长：2-4 小时                              │
├─────────────────────────────────────────────┤
│  层次二：流程建模（Process Modeling）          │
│  目标：细化事件流、识别命令和策略              │
│  参与者：开发者 + 领域专家                    │
│  时长：2-3 小时                              │
├─────────────────────────────────────────────┤
│  层次一：大图探索（Big Picture）              │
│  目标：发现所有领域事件，建立全局共识           │
│  参与者：所有相关角色                         │
│  时长：2-4 小时                              │
└─────────────────────────────────────────────┘

三、便利贴颜色与含义

事件风暴使用标准化的颜色来表示不同类型的领域概念。以下是 Brandolini 定义的标准颜色系统：

3.1 概念之间的关系

graph LR
    Actor["👤 参与者<br/>(黄色小)"] --> Command["📋 命令<br/>(蓝色)"]
    Command --> Aggregate["📦 聚合<br/>(黄色大)"]
    Aggregate --> Event["📌 领域事件<br/>(橙色)"]
    Event --> Policy["📜 策略<br/>(紫色)"]
    Policy --> Command2["📋 命令<br/>(蓝色)"]
    ReadModel["📊 读模型<br/>(绿色)"] -.->|"辅助决策"| Actor
    External["🏢 外部系统<br/>(白色)"] --> Event
    Event --> External

基本叙事结构是：参与者发出命令，聚合处理命令并产生领域事件，事件触发策略，策略可能导致新的命令。

四、层次一：大图探索

4.1 目标

在最短时间内建立对整个业务域的共同理解。不追求精确，追求全面。

4.2 步骤

步骤 1：混沌探索（5-10 分钟）

所有参与者同时在橙色便利贴上写下他们能想到的领域事件。每张便利贴写一个事件，用过去时态。不讨论、不争论，只管写。

"订单已下达"  "支付已完成"  "商品已发货"  "退款已申请"
"库存已扣减"  "优惠券已使用"  "用户已注册"  "评价已提交"

步骤 2：时间线排列（15-20 分钟）

把所有便利贴按时间顺序从左到右贴在墙上。这一步会自然引发讨论：

• “支付完成是在订单确认之前还是之后？”
• “库存扣减是在下单时还是支付后？”

这些讨论正是事件风暴的核心价值。

步骤 3：标记热点（5 分钟）

用粉红色便利贴标记所有有争议、不确定或需要进一步讨论的地方。

步骤 4：识别关键事件流（15-20 分钟）

从混沌中识别出几条核心事件流（通常是核心业务场景），用分隔线标记。

步骤 5：讨论和完善（30-60 分钟）

针对热点进行深入讨论，补充遗漏的事件，调整顺序。

4.3 大图探索的产出

时间线 →→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→

┌───────┐  ┌───────┐  ┌───────┐  ┌───────┐
│用户已  │  │商品已  │  │订单已  │  │支付已  │
│注册   │  │加入购  │  │下达   │  │发起   │
│       │  │物车   │  │       │  │       │
└───────┘  └───────┘  └───────┘  └───────┘
                                      │
                        ┌─────────────┘
                        ▼
                   ┌───────┐  ┌───────┐  ┌───────┐
                   │支付已  │  │库存已  │  │商品已  │
                   │完成   │  │扣减   │  │发货   │
                   │       │  │       │  │       │
                   └───────┘  └───────┘  └───────┘
                                              │
                                   ┌──────────┘
                                   ▼
                              ┌───────┐  ┌───────┐
                              │商品已  │  │订单已  │
                              │签收   │  │完成   │
                              │       │  │       │
                              └───────┘  └───────┘

[热点] 库存扣减时机：下单时还是支付后？
[热点] 退款流程：自动审批还是人工审批？

五、层次二：流程建模

5.1 目标

在大图探索的基础上，为每条核心事件流补充命令、参与者和策略，形成完整的业务流程模型。

5.2 补充命令和参与者

对每个领域事件，反向追问：

• 谁（Actor）触发了这个事件？
• 通过什么命令（Command）触发的？
• 做这个决定时需要看到什么信息（Read Model）？

[参与者]     [读模型]        [命令]        [聚合]      [事件]
 客户    →  商品详情页   →   下单     →   Order   →  订单已下达
 客户    →  支付收银台   →   支付     →   Payment →  支付已完成
 系统    →              →   扣减库存  →   Stock   →  库存已扣减
 仓库员  →  拣货清单     →   确认发货  →   Shipment→  商品已发货

5.3 识别策略

策略（Policy）是事件驱动的自动化反应规则。它描述的是”当 X 事件发生时，自动执行 Y 命令”。

策略识别模式：

[事件]               [策略]                    [命令]
订单已下达      →    当订单下达时              →  锁定库存
支付已完成      →    当支付完成时              →  确认订单 + 通知仓库
支付超时        →    当支付超过 30 分钟未完成时  →  取消订单 + 释放库存
商品已签收      →    当签收后 7 天无异议时      →  自动完成订单

5.4 策略的类型

六、层次三：软件设计

6.1 目标

将流程模型转化为可实现的软件设计，识别聚合边界、定义命令处理流程、设计读模型。

6.2 识别聚合

聚合的识别基于以下原则：

1. 处理一个命令并产生事件的实体集合构成一个聚合；
2. 必须在同一事务中保持一致的数据属于同一个聚合；
3. 不同的命令如果操作不同的数据集，通常意味着不同的聚合。

从事件风暴到聚合的推导：

命令 "下单" → 聚合 "Order"
  创建订单，包含行项信息
  产生事件 "OrderPlaced"

命令 "支付" → 聚合 "Payment"
  记录支付信息
  产生事件 "PaymentCompleted"

命令 "扣减库存" → 聚合 "Inventory"
  更新库存数量
  产生事件 "StockReserved"

6.3 从聚合到限界上下文

当多个聚合属于同一个业务领域、使用相同的通用语言时，它们通常属于同一个限界上下文。

graph TB
    subgraph "交易上下文"
        O["Order 聚合"]
        OL["OrderLine"]
        O --- OL
    end

    subgraph "支付上下文"
        P["Payment 聚合"]
        PR["PaymentRecord"]
        P --- PR
    end

    subgraph "库存上下文"
        I["Inventory 聚合"]
        R["Reservation"]
        I --- R
    end

    subgraph "物流上下文"
        S["Shipment 聚合"]
        T["TrackingEvent"]
        S --- T
    end

    O -.->|"OrderPlaced"| P
    O -.->|"OrderPlaced"| I
    P -.->|"PaymentCompleted"| O
    P -.->|"PaymentCompleted"| S
    S -.->|"ShipmentDelivered"| O

6.4 设计读模型

读模型（Read Model）是为查询优化的数据视图。事件风暴中识别的绿色便利贴直接对应系统中的读模型。

// 读模型：订单列表视图
public class OrderListView {
    private String orderId;
    private String customerName;
    private String totalAmount;
    private String status;
    private String paymentStatus;
    private String shippingStatus;
    private LocalDateTime createdAt;
}

// 读模型的投影器：监听事件，更新视图
public class OrderListProjector {

    public void on(OrderPlacedEvent event) {
        OrderListView view = new OrderListView();
        view.setOrderId(event.orderId().value());
        view.setTotalAmount(event.totalAmount().toString());
        view.setStatus("待支付");
        view.setCreatedAt(event.occurredAt());
        viewStore.save(view);
    }

    public void on(PaymentCompletedEvent event) {
        OrderListView view = viewStore.findByOrderId(event.orderId());
        view.setPaymentStatus("已支付");
        view.setStatus("待发货");
        viewStore.save(view);
    }

    public void on(ShipmentDeliveredEvent event) {
        OrderListView view = viewStore.findByOrderId(event.orderId());
        view.setShippingStatus("已签收");
        view.setStatus("已完成");
        viewStore.save(view);
    }
}

七、事件风暴的引导技巧

7.1 准备工作

7.2 引导者的关键行为

1. 打破沉默：如果参与者不知道从哪里开始，先写几个事件做示范；
2. 鼓励混沌：大图探索阶段不要追求秩序，混沌中会涌现洞察；
3. 追问”然后呢”：当事件流断裂时，问”这个事件发生之后会怎样？“；
4. 追问”之前呢”：当起点不清晰时，问”是什么导致了这个事件？“；
5. 标记热点：有争议的地方立即贴粉红色便利贴，不要当场解决；
6. 保护少数声音：确保领域专家的声音被听到，开发者不要主导讨论。

7.3 常见陷阱

八、远程事件风暴

8.1 工具选择

8.2 远程事件风暴的调整

远程环境下，事件风暴需要额外注意以下几点：

1. 缩短单次时长：线上注意力集中时间更短，每次不超过 90 分钟；
2. 提前准备模板：在工具中预设好颜色和区域；
3. 分组讨论：超过 8 人时先分组探索，再合并；
4. 录制过程：远程更容易遗忘上下文，录制便于回顾；
5. 投票功能：使用工具的投票功能标记热点。

九、工程案例：在线教育平台的事件风暴

9.1 背景

某在线教育公司计划重构其课程管理和学习系统。原系统是一个单体应用，所有功能耦合在一起。团队希望通过事件风暴重新理解业务，并设计新的架构。

9.2 大图探索结果

工作坊参与者包括 3 名产品经理、2 名课程运营、1 名教研负责人、5 名开发者。

主要事件流（简化版）：

课程管理流：
课程已创建 → 课程内容已上传 → 课程已审核通过 → 课程已上架

学员学习流：
学员已注册 → 课程已购买 → 学习进度已更新 → 课程已完成 → 证书已颁发

直播互动流：
直播间已创建 → 直播已开始 → 学员已加入 → 问答已提交 → 直播已结束 → 回放已生成

订单支付流：
订单已创建 → 优惠已应用 → 支付已发起 → 支付已完成 → 退款已申请 → 退款已处理

热点（共识不一致的区域）： - “课程已完成”的判断标准是什么？学完所有章节？还是通过考试？ - 退款策略：学完 30% 以上是否还能退款？ - 直播回放是否需要单独计费？

9.3 流程建模（课程购买流）

sequenceDiagram
    participant Student as 学员
    participant OrderAgg as 订单聚合
    participant PayAgg as 支付聚合
    participant CourseAgg as 课程聚合
    participant EnrollAgg as 选课聚合

    Student->>OrderAgg: 创建订单(courseId, studentId)
    OrderAgg-->>OrderAgg: OrderCreated
    Note over OrderAgg: 策略：计算优惠

    Student->>PayAgg: 发起支付(orderId, amount)
    PayAgg-->>PayAgg: PaymentInitiated

    PayAgg-->>PayAgg: PaymentCompleted
    Note over PayAgg: 策略：支付完成时

    PayAgg->>OrderAgg: 确认订单(orderId)
    OrderAgg-->>OrderAgg: OrderConfirmed
    Note over OrderAgg: 策略：订单确认时

    OrderAgg->>EnrollAgg: 创建选课(studentId, courseId)
    EnrollAgg-->>EnrollAgg: StudentEnrolled
    Note over EnrollAgg: 策略：选课后

    EnrollAgg->>CourseAgg: 更新学员数(courseId)
    CourseAgg-->>CourseAgg: EnrollmentCountUpdated

9.4 识别出的限界上下文

9.5 效果

• 2 小时的大图探索让所有人第一次看到了业务全貌；
• 识别出了 12 个热点，其中 3 个涉及重大业务规则分歧；
• 最终划分出 7 个限界上下文，对齐了 5 个开发团队；
• 从工作坊到首个服务上线用了 6 周。

十、从事件风暴到代码

10.1 事件风暴产出与代码的映射

10.2 Go 语言示例

// 命令
type CreateOrderCommand struct {
    CustomerID string
    CourseID   string
    CouponCode string
}

// 聚合
type Order struct {
    id         OrderID
    customerID CustomerID
    courseID    CourseID
    amount     Money
    discount   Money
    status     OrderStatus
    events     []DomainEvent
}

func NewOrder(cmd CreateOrderCommand, pricing PricingService) (*Order, error) {
    price, err := pricing.Calculate(cmd.CourseID, cmd.CouponCode)
    if err != nil {
        return nil, fmt.Errorf("计算价格失败: %w", err)
    }

    order := &Order{
        id:         NewOrderID(),
        customerID: CustomerID(cmd.CustomerID),
        courseID:    CourseID(cmd.CourseID),
        amount:     price.Original,
        discount:   price.Discount,
        status:     OrderStatusCreated,
    }

    order.events = append(order.events, OrderCreatedEvent{
        OrderID:    order.id,
        CustomerID: order.customerID,
        CourseID:   order.courseID,
        Amount:     order.amount,
        OccurredAt: time.Now(),
    })

    return order, nil
}

// 策略（事件处理器）
type EnrollmentPolicy struct {
    enrollmentRepo EnrollmentRepository
}

func (p *EnrollmentPolicy) OnOrderConfirmed(event OrderConfirmedEvent) error {
    enrollment, err := NewEnrollment(event.CustomerID, event.CourseID)
    if err != nil {
        return err
    }
    return p.enrollmentRepo.Save(enrollment)
}

// 读模型投影
type MyCoursesProjector struct {
    store ReadModelStore
}

func (p *MyCoursesProjector) OnStudentEnrolled(event StudentEnrolledEvent) error {
    view := MyCourseView{
        StudentID: event.StudentID.String(),
        CourseID:  event.CourseID.String(),
        Status:    "学习中",
        EnrolledAt: event.OccurredAt,
        Progress:  0,
    }
    return p.store.Save(view)
}

func (p *MyCoursesProjector) OnProgressUpdated(event ProgressUpdatedEvent) error {
    view, err := p.store.FindByCourseAndStudent(
        event.CourseID.String(), event.StudentID.String())
    if err != nil {
        return err
    }
    view.Progress = event.Percentage
    if event.Percentage >= 100 {
        view.Status = "已完成"
    }
    return p.store.Save(view)
}

十一、事件风暴的综合权衡

十二、下一步

事件风暴揭示了业务领域的事件流和上下文边界。当你需要将一个上下文与外部的遗留系统集成时，防腐层（Anti-Corruption Layer）和开放主机服务（Open Host Service）是两种关键的保护机制。

下一篇：防腐层与开放主机服务：系统集成的 DDD 方案

参考资料

1. Brandolini, Alberto. Introducing EventStorming. Leanpub, 2021.
2. Brandolini, Alberto. “Event Storming.” eventstorming.com.
3. Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
4. Vernon, Vaughn. Implementing Domain-Driven Design. Addison-Wesley, 2013.
5. Fowler, Martin. “Domain Event.” martinfowler.com.
6. Avram, Abel; Marinescu, Floyd. Domain-Driven Design Quickly. InfoQ, 2007.
7. Young, Greg. “CQRS and Event Sourcing.” cqrs.files.wordpress.com, 2010.
8. Rayner, Paul. “Event Storming Workshop Guide.” Virtual Genius, 2020.