事件风暴

事件深深植根于业务领域之中，领域内部的沟通也自然而然地围绕这些事件展开。不同的子领域会发送和消费这些事件，而这些交互将在未来被转化为软件实现。要理解一个领域的运作方式，我们必须首先理解其中的事件。人们可以采用一些方法来持续掌握领域中的需求、交互关系和约束条件，同时，每个需求、交互和限制的范围都应以清晰明确的方式界定，便于业务和技术专家共同理解。

为什么需要进行范围界定会议？

从领域专家那里提取系统需求并非易事。领域专家可能以某种方式描述业务流程，而技术人员的理解却可能不同。这容易导致构建出技术模型（例如使用UML），但这些模型往往难以被业务人员理解。因此，有必要组织一场双方使用共同语言交流的知识共享会议。这样可以让需求自然浮现，并使业务与技术双方都能轻松协作，共同建立准确的领域模型。

什么是事件风暴？

事件风暴是一种协作式工作坊，由 Alberto Brandolini 于2012年提出，旨在让技术专家与领域专家共同创建并分享对复杂业务领域和流程的理解。该方法已被科技行业广泛采纳，是技术团队从领域专家处获取业务知识的最佳途径之一。此外，事件风暴富有趣味性且易于操作，仅需便签纸和记号笔即可直观呈现业务流程信息。

开展事件风暴所需的条件

为确保事件风暴顺利进行，需满足以下基本要求：

• 使用不同颜色的便签纸。虽然事件风暴有标准配色方案，但允许调整颜色，唯一要求是保持一致性。
• 使用记号笔在便签上书写。
• 需要一个可粘贴便签的大面积表面，如墙面、大型白板或卷纸。
• 若线下开展，应选择光线充足、空间足够的房间；若线上进行，可使用Miro等协作工具。
• 事先简要说明会议目标和内容。
• 明确以下角色分工：
  • 引导者：负责组织会议进程，并确保全程遵循事件风暴的规则。
  • 领域专家：来自各个子领域的业务人员，其参与程度取决于待建模的业务流程和功能。
  • 技术专家：负责软件设计与开发的人员，需具备从业务专家处提炼需求的能力。

事件风暴中的核心元素

我们通过一个示例来分析和理解事件风暴的各个组成部分。假设某银行有一个“转账”子领域：客户希望将资金从银行A转至银行B。下图展示了从事件风暴视角看一次转账的过程。

事件风暴包含一系列规则、元素和注意事项，帮助参与者高效利用会议成果。首先，便签应从左到右排列，建议在展示区底部画出方向箭头以指示流程顺序。

不同颜色的便签代表不同含义：

• 橙色便签表示事件：指在领域中实际发生的动作，用过去时态表述，并采用领域专家的术语。
• 蓝色便签表示命令：体现某个参与者的行为意图，即“想要做什么”。
• 紫色便签表示策略：描述对某一事件的响应机制，即“当某事件发生时，应执行某命令或动作”。策略通常作为执行命令的前提条件，若条件不满足，甚至可能阻止命令执行。
• 黄色便签表示参与者（Actor）：发起命令的人或系统。
• 粉色便签表示第三方或内部系统：能够产生或接收事件的外部或内部服务。
• 红色便签表示问题或疑问：记录当前未解决的问题或待深入探讨的事项，供后续跟进。
• 绿色便签表示读模型：用于支持决策或操作的数据视图，可能来源于SQL查询、UI界面某部分或其他数据源，通常置于命令/事件对下方。
• 浅黄色便签表示聚合（Aggregate）：承载特定业务逻辑并具有明确职责的单元，有助于识别限界上下文。

事件风暴的实施步骤

为成功开展事件风暴，可参考以下步骤：

1. 梳理流程中发生的所有事件。
2. 明确触发这些事件的命令。
3. 补充可能在事件后触发的策略或反应机制。

上述步骤无需严格按序执行，可根据实际情况灵活调整。

1. 标注涉及的外部服务、疑问点及参与者。
2. 确定聚合与读模型。
3. 完成上述步骤后，将相关聚合归类分组，识别功能之间的边界。可通过圈出同类聚合来划分区域，此时时间线已无必要，可予以移除。

总结

事件风暴是一项强大的实践技术，能有效促进技术与业务人员对业务运作机制的共同理解。它促使所有参与者聚焦于业务流程本身，最终形成一个双方共识一致、语义清晰的领域模型。