使用事件风暴探索业务全景

简介: 使用事件风暴探索业务全景

本文介绍了如何使用事件风暴探索系统的业务全景,是深度介绍事件风暴方法的第一部分。

image.png

事件风暴

事件风暴是一种高度强调交流与协作的可视化工作坊,是大白纸与各色即时贴的重度使用者。面对着糊满整面墙的大白纸,工作坊的参与人员通过充分地交流与沟通,然后用马克笔在各色即时贴上写下各个领域模型概念,贴在墙上呈现生动的模型。由于这些模型都是可视化的,就可以给团队直观印象。大家站在墙面前,观察这些模型,及时开展讨论。若发现有误,就可以通过移动即时贴来调整与更新,也可以随时贴上新的即时贴完善建模结果。

image.png

Alberto Brandolini

Alberto Brandolini设计的事件风暴通常分为两个层次。如果在工作坊过程中将主要的精力用于寻找业务流程中产生的领域事件,则这个过程可以认为是宏观级别的事件风暴,其目的是探索业务全景(Big Picture Exploration)。在识别出全景事件流之后,就可以标记时间轴的关键时间点作为划分领域边界和限界上下文边界的依据;同时也可以基于事件表达的业务概念对领域进行划分,最终确定候选的子领域和限界上下文。

另一个层次则属于设计级别(Design-level)的领域分析建模方法,通过探索业务全景获得的事件流,围绕着事件获得领域分析模型。这些领域分析建模要素除了领域事件之外,还包括决策命令、读模型和聚合。事件风暴的领域分析建模方法通常会以业务全景探索的结果作为领域分析建模的基础。


探索业务全景


在探索业务全景的过程中,为了使每个人保持专注,一开始要排除其余领域概念的干扰,一心寻找沿着时间轴发展的事件。事件是事件风暴的主要驱动力,寻找出来的事件则是领域分析模型的骨架。事件风暴使用橙色即时贴来代表一个事件(Event)。

事件风暴工作坊要求沿着时间轴对事件进行识别。通常的做法是由领域专家贴上第一张他/她最为关心的事件,然后由大家分头围绕该事件写出在它之前和之后发生的事件,并按照时间顺序由左向右排列。以信用卡申请开卡的业务为例,领域专家认为“开卡申请已审批”是我们关注的核心事件,于是就可以在整面墙的中间贴上橙色即时贴,上面写上“开卡申请已审批”事件:

image.png

在确定这个核心事件之后,我们就要以此为中心,向前推导它的起因,向后推导它的结果,根据这种因果关系层层推进,逐渐形成一条或多条沿着时间轴且彼此之间存在因果关系的事件流:


image.png

在识别事件的过程中,工作坊的参与人员应尽可能站在管理和运营的角度去思考领域事件。这里所谓的“因果关系”,也可以理解为产生事件的前置条件是什么,由此推导出前置事件;事件导致的后置条件是什么,由此推导出后置事件。

从“开卡申请已审批”事件往前推导,它的前置条件是什么呢?显然,只有在信用卡申请人提交了开卡申请之后才可能审批申请,由此得到前置事件“开卡申请已提交”。以此类推,“开卡申请已提交”的前置条件又是什么呢?申请人在提交申请信息之前,需要通过征信系统对填写的内容做征信预检,于是可推导出前置事件“征信预检已完成”:

image.png

从“开卡申请已审批”事件往后推导,它的后置条件是什么呢?如果开卡申请通过了,一方面保证申请人收到审批结果通知,另一方面则开始制卡,首先就需要保证信用卡号已经生成,由此得到两个并行的后置事件“卡号已生成”和“审批结果已通知”。接着,在“卡号已生成”事件之后,就是等待制作信用卡的结果,由此获得后置事件“信用卡制作完毕”:

image.png

事件风暴是一种探索性的建模活动。在探索事件的过程中,我们不要急于去识别其他的领域对象,基于事件结果,也不要急于去寻找导致事件发生的起因。尤其是在探索业务全景期间,更要如此。毕竟人的注意力是有限的。

从一开始,就应该让工作坊的参与人员集中精力专注于事件。倘若存在疑问,又或者需要提醒业务人员或技术人员特别注意,可以用粉红色即时贴来表达该警告信息,Alberto Brandolini将其称之为“热点Hot Spot”。例如针对“开卡申请已审批”事件,需要考虑审批未通过的异常情况;“卡号已生成”事件需要考虑不同类型的信用卡需遵循不同的卡号生成规则;“审批结果已通知”事件可以标记系统支持的通知方式:

image.png

如前所述,触发事件的起因包括三种可能。在事件风暴业务全景探索过程中,可以在获得全景事件流之后,判断各个事件的起因,并分别用不同颜色的即时贴进行标记:

  • 由用户活动触发:标记参与事件的用户角色,用黄色小即时贴绘制火柴棍人表示
  • 当条件满足时:标记引起事件的策略,用紫色即时贴表示
  • 外部系统:标记引起事件的外部系统,用浅粉色即时贴表示

前面获得的事件流可以表示为:

image.png

不要小看对这些事件起因的标记。在完成全景事件流之后,对事件的起因进行再一次梳理有助于团队就识别的事件达成一致,检查事件是否存在疏漏、谬误之处。作为事件起因的用户、外部系统与策略还为后面的领域分析建模奠定基础。其中,识别出的外部系统也有助于未来的架构设计,帮助我们绘制《领域驱动战略设计实践》课程中讲到的C4模型中的系统上下文(System Context)图。

相关文章
|
测试技术 领域建模 数据安全/隐私保护
运用事件风暴进行领域分析建模
运用事件风暴进行领域分析建模
运用事件风暴进行领域分析建模
|
测试技术 领域建模 定位技术
基于事件风暴的需求分析 | 方法案例一
事件风暴(Event Storming)源自领域驱动设计社区,由 Alberto Brandolini 在2012 年发明[1]。 事件风暴最早的名字是基于事件的建模(Event-Based Modeling),正如这个名字所暗示的,事件风暴在发明之初的核心目的是领域建模,在今天的大多数文献和实践中,事件风暴的核心关注点都是领域模型和软件架构。
3805 2
基于事件风暴的需求分析 | 方法案例一
|
5月前
|
领域建模
领域建模问题之事件风暴的主要特点是什么
领域建模问题之事件风暴的主要特点是什么
03、组件间的通信(头脑风暴)
03、组件间的通信(头脑风暴)
|
存储 设计模式 监控
流程级事件风暴
流程级事件风暴
|
数据可视化 架构师
什么是事件风暴?
什么是事件风暴?
|
UED 微服务
事件风暴的设计要素与驱动力
事件风暴的设计要素与驱动力
事件风暴的设计要素与驱动力
|
SQL 测试技术 API
事件风暴过程全体验-下篇
事件风暴过程全体验-下篇
事件风暴过程全体验-下篇
|
数据采集 运维 监控
治理告警风暴,告警降噪的一些典型手段
很多公司希望提升服务稳定性,而上线了各类监控系统,指标的、链路的、日志的,而且只是指标层面可能就会有多个监控系统,这么多监控系统、这么多监控目标,如果没有良好的治理,很快就会产生告警风暴的问题,如何通过一些手段达到告警降噪的效果呢?
449 0