DDD技巧：你知道如何正确使用“事件风暴”来划分领域吗？

surfirst

已于 2022-04-30 18:40:49 修改

阅读量1.4k

点赞数

分类专栏：架构文章标签：敏捷开发需求分析 DDD

于 2022-03-08 15:34:25 首次发布

本文链接：https://blog.csdn.net/surfirst/article/details/123301305

版权

架构专栏收录该内容

100 篇文章

订阅专栏

事件风暴 (Event Storming) 是意大利软件开发专家 Alberto Brandolini 在 2013 年发明的一种让领域专家和开发人员一起合作探索、研究业务领域的一种方法。

在事件风暴出现之前，软件设计人员使用 UML 图等专业工具和领域专家交流业务建立统一语言和领域模型，但是由于像 UML 图之类的专业工具很难被领域专家理解，在各方的讨论过程中缺少系统的方法，这就造成了交流效率不高。

事件风暴和大多数敏捷实践一样，讲究团队合作，集思广益。事件风暴使用便签这种简单工具，让参与人员列出领域事件，基于时间线对领域事件排序，然后讨论业务问题，促进开发人员和领域专家的沟通，既可以输出 DDD 需要的领域划分策略，聚合等，也可以根据优先级输出 Epic, Feature 和 User Story。

谁来参与？

简单地说，除了一个主持人以外，还需要包括下面这些人员：

业务专家
IT
交互工程师

IT和交互工程师都是开发人员，这里更重要的人员是业务专家。事件风暴的目的是通过交流让团队可以形成对业务的全面了解。在现实世界中，人和人对业务的理解总会有差异，在各自的工作中由于工作重点的不同，看到的世界就会不一样，一次完美的事件风暴应该邀请组织内部不同部门的专家都来参加。比如电商业务，就可以邀请订单、配送、支付、财务等各方面的专家都来参加。

我们需要打破隔阂 (Silo) 产生思想的撞击，就像 “华山论剑” 一样，必须产生交锋，而不只是文字游戏。

如何开始？

准备工作

首先主持人要准备以下内容：

足够的大的空间 (公屏)
每个人一只马克笔
各种颜色的便笺，越多越好

需要足够的大的空间是因为一次全景范围 (Big Picture) 的事件风暴可能需要容纳成百上千的的便签。

这是一场需要每个参与者都贡献内容的活动，所以每个人都需要有一只笔在便签纸上写出自己的想法，贴到“公屏”上。

不同颜色的便签表示不同的示例，用的最多的是用来书写“领域事件”的便签，一般用桔黄色来表示，除了领域事件以外还会需要下面的便签表示的内容：

命令 (Command)
外部系统 (External System)
政策 (Policy)
用户 (User)
查询 (Read Model)

在这里插入图片描述
政策表示了命令和领域事件之间的依赖关系。比如“申请了退货”这个事件是“用户”根据退货“政策”执行了“退货”这个命令以后的结果。

查询 (Read Model) 这个概念来自于 CQRS (Command and Query Responsibility Segregation)，在“事件风暴” 里可以理解为在产生“事件”之前决策所依赖的数据。

开场白

主持人的开场白以引导为主，包括以下内容：

介绍业务背景和目标
理论上说参与者都应该对需要分析的业务已经有所了解，主持人可以再介绍一下业务背景和目标。
说明什么是领域事件，让大家从领域事件开始
领域事件是领域专家关心的和业务相关联的事件，主持人应该说明它不是开发人员在软件开发中经常遇到的 UI 事件。领域事件应该用过去时来表达。所有参与者在接下来的过程中需要尽可能地写出能够想到的领域事件。
控制范围，主持人画出时间线，贴出开始和结束事件
为了防止过于发散，主持人可以在“公屏”上先贴出开始事件和结束事件的便签，这样可以建立逻辑线条，让参与者的思考如何把自己的领域事件贯穿始终。

事件风暴的过程和注意事项

主持人完成准备工作，讲完开场白以后就可以宣布开始“事件风暴”了。“事件风暴”也是一种“头脑风暴”，它需要每个人的积极参与贡献内容。下面列出了“事件风暴”的大致步骤：

所有的参与人在10分钟内尽可能的写出可能想到的领域事件
时间结束后，参与人把自己的领域事件便签添加到“公屏”上
主持人和所有参与人一起去掉重复的事件，然后对剩下的领域事件标签按照时间线排序

以上活动的目的是让大家从“私有时间线”通过对话和讨论转到“共享时间线”，在“公屏”上看到对概念理解的异同，产生交锋，形成共识。

在讨论的过程中，可以进一步的细化“领域事件”，使用不同颜色的便签标记出上文中提到的“用户”、“命令”、“外部系统”、“策略”、“查询”等项目。

通过事件风暴，我们可以得到下面的成果：

提取用户故事
我们可以使用“影响地图” (Impact Mapping) 等方法，抽取“公屏”里的便签根据优先级提取出用户故事。
划分领域
根据特定的概念，画出领域。
找到聚合
有一类概念它们之间会根据状态变化产生联系，内部状态可以用状态机来描述，它就有可能是聚合。比如在电商系统里围绕着“订单”的一系列事件和变化，“订单”就可能是一个“聚合”。