事件六要素与DDD事件风暴

     

 

 

可以将“时间、地点、参与者、事件起因、事件经过与结果”这些要素类比到事件风暴（Event Storming）的结构中。这种类比有助于更直观地理解事件风暴中的各个组成部分，并且可以在实际应用中帮助团队更好地组织和讨论业务流程。以下是如何进行类比的具体说明

### 1. 时间 (Time)

- **类比到事件风暴**：虽然事件风暴不特别强调具体的时间点，但它确实关注事件发生的顺序。通过将领域事件按照时间线排列，可以帮助团队理解业务流程的时间发展。在事件风暴中，通常会使用一条水平线来表示时间轴，事件便签按顺序贴在这条线上。

 

### 2. 地点 (Location)

- **类比到事件风暴**：地点可以类比为限界上下文（Bounded Context）。限界上下文定义了系统中不同部分的边界，每个上下文都有其特定的规则和模型。不同的地点可能对应不同的限界上下文，例如，订单处理可能在一个上下文中，而支付处理可能在另一个上下文中。

 

### 3. 参与者 (Actor)

- **类比到事件风暴**：参与者直接对应于事件风暴中的参与者（Actor）。参与者是指发起命令或响应事件的人或系统。在事件风暴中，参与者通常用小黄色便签表示。例如，用户、管理员、外部系统等都可以是参与者。

 

### 4. 事件起因 (Cause of the Event)

- **类比到事件风暴**

 - **事件风暴的动作 (action)**：

  - **读模型 (Read Model)** 和 **策略 (Policy)**：如前所述，读模型和策略提供了做出决策所需的信息和规则，它们可以被视为事件起因的一部分。例如，库存查询（读模型）和库存检查策略（策略）共同决定了是否允许提交订单。

  - **外部事件 (External Event)**：外部事件也可以作为事件的起因。例如，第三方支付网关的“支付成功”事件可能触发订单状态的更新。

 

### 5. 事件经过 (Process of the Event)

- **事件风暴的命令 (Command)**：命令是由参与者发起的意图表达，它可能是事件的直接起因。例如，“提交订单”命令可能导致“订单已提交”这个领域事件。事件经过对应于聚合（Aggregate）内部的业务逻辑处理。在这个阶段，聚合根据接收到的命令或外部事件，结合读模型提供的信息和策略规定的规则，进行一系列的操作和验证，最终决定是否改变其状态。例如，当接收到“提交订单”的命令后，订单聚合可能会验证库存、计算总价、生成订单号等。

 

### 6. 事件结果 (Outcome of the Event)

- **类比到事件风暴的事件**事件结果直接对应于领域事件（Domain Event）。领域事件反映了业务流程中的关键变化，并且一旦发生就不可改变。例如，“订单已提交”、“支付成功”、“货物已发货”都是领域事件的例子。这些事件不仅记录了系统的状态变化，还可以触发后续的业务流程或其他系统的响应。

 

### 综合示例

假设我们正在分析一个在线购物平台的订单处理流程：

 

- **时间**：我们将所有事件按照时间顺序排列在一条水平线上，从用户点击“提交订单”开始，到订单状态更新为“已发货”结束。

  

- **地点**：订单处理可能在一个限界上下文中进行，而支付处理可能在另一个限界上下文中进行。

 

- **参与者**：用户（提交订单）、支付网关（处理支付）、仓库管理系统（处理发货）等。

 

- **事件起因**：

  - 用户点击“提交订单”按钮（命令）。

  - 系统查询库存和购物车内容（读模型），并检查是否有足够的库存（策略）。

  - 第三方支付网关返回“支付成功”事件（外部事件）。

 

- **事件经过**：

  - 订单聚合接收到“提交订单”的命令后，验证库存、计算总价、生成订单号。

  - 支付聚合接收到“支付成功”事件后，更新订单状态为“已支付”。

 

- **事件结果**：

  - 系统发出“订单已提交”和“订单已支付”两个领域事件。

  - 仓库管理系统接收到“订单已支付”事件后，准备发货，并发出“货物已发货”事件。

 

其实相信大家小学的时候写作文必备的 事件六要素都应该非常懂。自不必多教。所以事件风暴也没那么复杂，本质其实是“外来的和尚会念经”而已。通过将“时间、地点、参与者、事件起因、事件经过与结果”这些要素类比到事件风暴的结构中，我们可以更清晰地理解和组织业务流程。这种类比不仅有助于团队在事件风暴工作坊中更有效地讨论和建模，还能确保所有关键因素都被充分考虑，从而构建出更加准确和完整的领域模型。