捕获需求的利器——领域驱动设计中的事件风暴 _领域驱动设计

1.事件风暴是什么
需求分析作为许多研发同学接触到的软件开发流程中的第一个环节，经常会碰到一些无从下手的问题，还会碰到分析不透彻导致后期大量返工的问题，下面来介绍下DDD中推荐的一种需求分析方法——事件风暴（Event ），帮助团队快速厘清需求、熟悉业务知识与接手已有项目。
在软件工程实施中，往往都是从捕获需求开始，具体来说就是分析系统具有哪些功能、这些功能由什么人来操作、操作之后会产生什么效果。在传统面向对象开发方法中常用的Use Case，也就是描述用户用例，扩展成用户故事。DDD推行的则是事件风暴，2003年Eric Evans的DDD著作中没有对需求捕获做实现方式约束，2013年提出的事件风暴很好地做了补充。
事件风暴工作坊对事件风暴是什么以及可以解决的问题做了精要描述：
is aforof.
It comes in, that can be used in:
Theofcross-with,a new type ofsilo and.
简单来说，事件风暴借助头脑风暴的形式，通过领域事件表达业务流程，用于协作探索复杂的业务领域。
可以用于评估现有业务的健康状况并找到有效的改进措施，也可以用于探索创新商业模式的可行性，还可以用于设计新的服务方式满足各方收益，当然关注最多的还是用于设计整洁可维护的事件驱动型软件，支持业务快速发展。
事件风暴总的来说就是将业务人员与技术人员拉在一个对话空间内做头脑风暴，捕获行为需求，消化领域知识，形成统一语言的方法。
2.事件风暴的价值
事件风暴抓住了企业软件开发的痛点——协作问题，以事件为核心允许不同背景的利益相关方展开对话，并超越各自专业背景界限。
在企业软件不断腐化的过程中，领域知识的遗失、理解偏差、信息孤岛等是重要影响因素，而事件风暴通过重视可视化的头脑风暴的形式可以快速建立核心业务流程，将领域知识深入高效地散播到整个团队。围绕业务开展软件研发而不是技术是企业软件开发的特点，因此协作显得尤为重要。事件风暴旨在解决这一痛点，使业务人员与开发人员通过最终达成统一语言的方式建立沟通渠道、保持信息对等。
对事件风暴划分了几种形式，我们主要看Big 和 Level这两种。
前者侧重业务方，所有的干系人都需要参与，探索业务全景，发现热点（Hot Spot），互补不同专业背景知识，有点像国内的需求宣贯或需求评审；后者侧重研发团队内部，梳理业务流程，传播业务知识。
3.如何开展事件风暴
事件风暴的执行一般分为三步，识别领域事件、识别命令和识别聚合。
当然在事件风暴之前，还有业务背景、产品愿景、关键目标等诸多环节，这些不在DDD考虑范畴之内，有机会另说。
下面就跟随一个例子来开展一次事件风暴，举例可能存在不完善的地方也说明了这是一个需要反复迭代的过程，每一次领域知识的重新认知、业务规则的重新挖掘、需求变更都会导致事件风暴的结果出现变化，我们拥抱这种变化。
3.1 事件风暴准备
在开展事件风暴前，需要协调好干系人与头脑风暴开放空间。
干系人包括领域专家或产品经理、项目经理、架构师、开发测试同学等，在准备好的大白板及各色贴纸卡片上集中探讨。在数小时的话语机锋中，横挪交错的不断糊墙中，思维发散又收敛，不断往复，需求愈辨愈明最终得以浮出水面，看到一条条事件流水线。
就这样，一位领域专家走到白板前，介绍起一个日常生活中经常遇到的事情开始我们的事件风暴。
在当今，安防监控日益普及，不论是公安交通还是企业工厂，出现各式各样的感知设备比如抓拍点位，通俗说就是摄像头、相机。这些点位诞生的最初原因就是为了自动识别布控人脸车辆等对象，来代替费时费力的人工值守研判，大幅提高安防效率。
比如说大型企业园区数字化转型需要对机密地带做监管，及时发现非法闯入人员，就会有指定区域人脸布控的需求，不在合法名单内的人员会触发报警；再比如说电视上常报道的获取盗窃线索，就会有对特定地段时段做人脸布控的需求，及时上报抓拍预警寻求相似特征，研判分析嫌犯了解嫌犯作案动向。
我们就抽取通用的行为需求，以布控和告警构建最基本的安防体系。
用户可以对指定时段指定点位进行布控，布控对象包括人脸、机动车和非机动车，通过布控任务下发布控行为，布控下发后可以撤销还可以继续布控，当布控时段到期后布控任务终止不可再操作。
在布控过程中满足布控条件就会触发预警，预警会推送给指定用户，这个也要在布控任务创建时选择，用户接收到告警后进行专业处理，系统不再干涉。
当然在布控任务创建时，要添加好用户和点位。这里区分下了添加和创建，用户和点位本身已经具备录入到系统称之为添加，布控任务本身并不存在称之为创建，算是根据领域知识初步建立了统一语言。
3.2 识别领域事件
准备工作后，由领域专家或产品经理介绍业务背景，进入事件风暴环节首先要做的是识别领域事件（ Event）。
所谓领域事件，就是业务流程中每个环节引发的结果，按照英语语境是完成时+被动语态来表述。实践证明从结果出发描述业务会比操作及过程性的更清晰容易。
领域事件可以由参与者任意提出，共同探讨出核心事件，按照大致的业务时序推导出前因与后果。
这里需要注意的是不能把技术事件当成领域事件，领域事件由领域专家所关注，必须使用业务术语，这样业务人员与开发人员才有沟通的渠道。像数据库回滚、缓存失效都不是领域事件。
再者，查询功能也不能列为领域事件。领域事件是执行了操作对事物产生了影响而被记录的事件，比如说增删改。
对其他系统产生影响属于领域事件，比如发送消息、邮件通知、调用服务等。
我们继续举例。
通过领域专家的业务需求描述，大家七嘴八舌展开讨论，在白板上不断贴纸挪动，确定了两条事件流。梳理了布控管理与告警管理两个流程，对每个流程做分解识别关键领域事件，按照业务流程时序大致排列这些事件。
在布控开始前，需要添加用户和点位，然后是布控状态的变化，或者说是布控生命周期。从而达成一致，先确定了用户已添加、点位已添加、布控已创建、布控已撤销、布控已终止这几个事件。
这时有研发同学提出来，布控创建后可能并不会立即下发，要是布控时段再未来某段时间布控就不需要下发，也不会触发告警的。大家想了想觉得有道理，于是在布控已创建事件后加入了一张贴纸——布控已下发。
对告警的关键事件梳理就容易得多，在布控下发后，触发布控条件产生告警，统一接收告警，查找下关联布控任务，最后将告警推送给指定用户。
至于用户查询、布控任务关联等功能没有对布控或者告警本身产生影响，因此没有作为领域事件列出。以结果看业务，能够抽象出业务的核心流程，这些结果最终是很有可能落到数据库层面的，产生系统级影响。
3.3 识别命令
然后要做的是根据事件识别命令（）。所谓命令，就是引发领域事件的操作。
常用命名方式就是将领域事件转换成动宾短语。
命令需要执行者，也就是角色（Actor）。包括用户指令、其他系统触发、系统规则（比如定时任务）。
如果涉及关联其他数据，还需要将查询数据标记出来。
识别了领域事件后，识别命令快了许多，大家换了一种蓝色贴纸布置在各个领域事件贴纸上用来记录触发领域事件的命令，又加了一种粉色贴纸记录命令的执行者，再加一种绿色的贴纸记录重要的关联查询数据。
这时候会有一些刚刚讨论的业务内容没有记录在白板上，比如布控任务创建时要选择布控对象，这一步没有作为领域事件列进去是因为属于其中一部分，但是不写入事件就会丢失。怎么办呢，大家又换了一种灰色的贴纸写下来，作为业务规则补充到对应的领域事件下方。
经过一通操作大家觉得当前必要的元素梳理差不多了，整理了下白板变成了这个样子，初步的领域事件与命令识别完成了。
在识别命令的过程中，也能对重要业务规则做梳理，事件风暴本身不对需求做完备记录，但是可以直观了解核心业务流程，这些业务规则最终会落到一个个实现层面的判定条件。
3.4 识别聚合
最后，聚类寻找聚合，用领域名词表示。他们从领域事件与命令汇集，是事件流不同位置的同一概念。
重新组织这些贴纸卡片，把围绕一个名词的所有元素聚集在一起，如果出现在多个名词堆中则用数字进行标号。聚合为接下来确定限界上下文、划分实体与值对象以及验收测试打下基础。
【捕获需求的利器——领域驱动设计中的事件风暴】下面进入到名词识别与归纳环节，白板上的名词尽数归类，变成了一个个围绕记录领域名词的黄色贴纸的堆。
对于布控任务和告警消息大家意见基本一致，但是对于用户和点位怎么划分呢，普通用户和管理员是否应该单独作为聚合存在，现在还不清楚，我们就先归为用户，在领域建模的时候再来思考。
白板现在变成了这样，当然，以电子白板呈现会规整一些。
3.5 记录事件风暴
事件风暴这两个收尾工作不能忽视。第一个就是如何记录，对于复杂软件某个迭代的需求讨论或者业务呈现上面过程称为糊墙一点儿不为过，怎么记录存储保持更新呢，在没有用户故事、功能列表的输出前提下，可以通过表格暂时记录。
就像下面这样。
3.6 记录业务规则
再一个容易被忽视的是业务规则的记录。业务规则是领域知识的重要组成部分，随着建模深入，业务规则也会被不断挖掘调整，需要一份记录伴随迭代保持更新状态。
就像下面这样。
4.继续深入
作为重视的需求分析方式，事件风暴不对需求规格做像UML、PRD等严谨细致的探讨，而是高效协作，快速建立业务概念。能够让研发围绕业务开展软件设计，重视业务知识的发掘传递，让业务与研发有机会共同决策产品或项目的发展，将产研团队更紧密的结合在一起。
事件风暴自2013年提出以来，与DDD走得越来越近，它在软件分析方面的贡献逐渐得到业界认可，更深入地，可以查阅接近完稿的事件风暴著作。
参考