前情回顾
2015年下半年，我们开始做一套WEB版的内部业务系统，业务逻辑也很简单，我们选择了能快速搭建产品的Yii2框架来实现，随着时间的推移，业务逻辑越来越多，我们的项目就像一个泥球一样越滚越大，越滚越沉重，每个新加入的开发者甚至见证项目成长的开发者看着代码都是前不着文，后不着调，BUG频频，维护困难，一些奇怪的问题查不到原因，从开始到现在，业务人员和开发人员已经被项目培养了好几波，业务知识也随着人员的流动离职了，只有散落在“泥球”里的字母和单词颤颤巍巍的默默运行着……
我们都玩过切水果，没错，我们期望着能有一把这样锋利的“水果刀”，把我们的大泥球快速切割，让我们能够看清里面的业务逻辑，现在我们找到了，其实我们的最终目的是在有限的时间内快速梳理业务全貌，并快速建立业务模型，让我们开始干货吧。
事件风暴
大家都知道，万事万物的成长都是在一段时间内发生了一些有顺序的事件形成的，而我们用软件开发的所有系统都是对现实生活中业务逻辑的模型，所以我们从一系列发生的事件就基本可以了解我们业务系统的全貌，所谓风暴，即头脑风暴。
事件风暴的优点
- 这是一种有很强参与感的方法，每个人都拿着一叠便利贴和马克笔，随时可以加入学习和设计的讨论中，业务人员和开发人员在平等的基础上共同学习，我们所使用的语言都是被大家所理解的，而不是讨论业务人员无法理解的数据库，对象，类，等等概念；
- 它令每个人都聚焦于事件业务流程，而不是类和数据库；
- 这是一种高度视觉化的方法，消除了实验过程中的代码，让每个人平等的参与到设计过程中；
- 实施起来非常快，投入成本很低，只需花几个小时，而不用数周就差不多可以通过头脑风暴得出粗略的核心领域模型；
- 团队成员无一例外地会取得对业理解的突破；
- 每个人都能学习到业务知识，无论是业务还是开发人员都会带着对现有模型的新鲜且清晰的理解离开讨论。在许多项目中，一部分甚至大多数项目成员根本不了解他们的工作内容，直到代码出现问题，才发现为时已晚。快速产出的模型能帮助每个人消除误解，朝着统一的方向和目标前进；
- 细粒度的事件为开发人员后续的研发提供了模型设计。
参与人员
可以召集包括领域专家、业务、开发、测试、运维在内的团队所有成员
实施步骤
- 准备材料
我们需要准备各种颜色的便利贴，颜色越多好好，记号笔，和长卷白纸（1Mx10M）
2. 邀请包含领域专家在内的团队所有成员参加
团队所有成员包括业务、开发、测试、运维等各个角色，其中“知道答案”的业务专家是必不可少的
3. 贴事件（橙色）
请业务专家贴第一张他/她最关心的领域事件。在便利贴上用“名词+动词过去式“的形式来写事件。然后大家同时分头各自写这个事件之前和之后发生的其他事件，并按发生的事件顺序从左到右排序，按照业务流程，有的事件会和其他事件并行发生，那就贴在该事件下方，这样就可以使用纵向空间来表示并行处理
4. 发现问题，记录（紫红色）
在事件风暴讨论中，会在已有或者新的业务流程中发现问题点，把它记录在紫红色的便利贴，并用一段文字解释为什么它是一个问题，会后加深学习该问题知识
5. 事件导致流程（浅紫色）
有时候事件将导致一个需要执行的流程，流程可以是一个单独的步骤，也可以是多个复杂的步骤，记录该流程到浅紫色便利贴，从发生的事件绘制一条带箭头的连线，并指向这个流程。
如果我们已经穷尽了所有的事件，那么我们进入下一个环节
6. 贴命令（浅蓝色）
在浅蓝色便利贴上写下导致每个事件发生的对应命令（Command），通常的格式是“动词+名词“，把代表命令的浅蓝色便利贴紧挨着摆放在由它引起的事件的左边，它们被成对的关联在一起，命令/事件，命令/事件，命令/事件......
7. 发现重要角色（亮黄色小型便利贴）
如果存在一个执行动作的特定重要角色，可以在命令的左下角贴上一张亮黄色的小便利贴，画上小人，并写上角色名称
8. 命令导致流程（同第5点处理）
9. 一个命令导致多个事件发生，这很正常，创建一个命令，把它摆放在那些由它引起的所有事件左边
10. 找到“命令/事件”的载体，通常叫做“实体/聚合”（淡黄色）
用淡黄色的便利贴表示所有命令/事件的载体，通常是一个名词，并把其对应的命令，事件分别贴在聚合的左右下角，达到这一步骤的时候，你可能发现一个聚合被反复利用，不要做任何调整，继续按照规则贴上相同的便利贴
11. 绘制边界和表示事件流动的箭头连线，你非常有可能在下面这些条件满足时发现边界
- 部门分界出现时
- 不同业务人员对相同的术语的定义出现冲突时
- 出现非常重要但不属于核心领域的某个概念时
注意，我们必须确认边界准确时，再使用马克笔绘制边界，否则可以使用其他颜色的小型便利贴暂时分界
12. 命名边界区域名称（粉红色）
把粉红色的便利贴，贴在各个区域内，并写上表示该区域内容的名字，然后绘制箭头连线，表示限界上下文之间的事件流动方向
至此，我们的产品全貌应该出现在大家的视野里了。
我们的长卷纸上应该出现类似下面这样的图
接下来要做的工作
完成了事件风暴之后，如果发现比较宏观，那我们应该调整事件级别，以较细粒度的事件补充我们的事件，直到接近最基本的设计级别的模型
梳理各个限界上下文的需求，编写用户故事，形成开发任务
我们还可以引入“假如/当/那么（Given/When/Then）“的格式编写可执行的高级需求说明，并编写测试用例，使用TDD（测试驱动开发）
下一次补充任务识别与工作量估算……
参考资料《领域驱动设计》《实现领域驱动设计》《领域驱动设计精粹》
扫一扫
159
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
