敏捷开发与项目管理程序员需求与用研

Event-Storming 工作坊:探索业务全景

2018-06-12  本文已影响113人  谢小呆呆呆

最近在公司内部组织了几场 Event Storming Workshop,这篇文章算是作为组织者交付的一份作业,希望更多同学可以了解并且组织这样的活动。

背景

假设我们是一家 B2C 的电商平台,姑且就叫做 “京西” 商城,创业一年多,创业初期野蛮生长,系统也是 “大泥球(单体应用)” 。公司发展很好,又融资 2000万美金,公司业务需要迅速扩张,而现有系统难以支撑公司业务的快速发展,需要进行微服务的拆分,同时开发团队的规模也要从过去的 20 人增加到 100 人。

新加入的同学需要快速了解现有业务,而产品经理也无法对所有业务进行完整描述,过去的开发人员只了解局部业务。业务需求无论是 “用户故事” 还是厚厚一沓需求文档,都难以让新老同学有一个快速的统一的完整认知。

Event Storming

针对以上的种种困难,我们可以采用 Event Storming 轻量级建模工具,来帮助我们较短的时间内快速理解业务的全景,达到统一的认知。

Event Storming 是按照 DDD(Domain Driven Design)的思想所派生出来的建模工具,当我们使用 Event Storming 去探索业务全景的同时,也产出了对业务系统的建模设计,这是与 User Journey 、用户故事地图(User Story Mapping)工具的最大区别。

原则:通用语言

在过程中我们需要遵守的重要原则是通用语言 (并不是其他原则不重要,而是我没记住,哈哈)。通用语言在 DDD 中也是重要原则之一。有两层含义:

准备工作

寻找一个风和日丽的下午,一个大会议室,还要有一个巨大的白板、各种颜色的便签贴。

带有时间轴的白板

邀请上我们所有需要了解业务的同学:

我们可以邀请所有的相关人员,必不可少的是我们的领域专家,在没有领域专家的指导下我们很容易会按照自己的理解而走偏。

如何开始?

首先,由领域专家将业务背景进行一个大致的介绍,不需要很全面,让大家有一个基本的认识,然后按照如下步骤操作。

根据经验,如果参与的同学对业务完全陌生会导致两个极端:1. 所有人只是在观看领域专家在贴,无法参与其中。2. 人们在根据自己的理解胡乱贴便签,而领域专家需要不断纠正。虽然出现不同的想法是我们所希望看到的,但大量的纠正会导致时间上的浪费。

领域专家带领大家找到系统中认为最重要的领域事件,贴在我们的带有时间轴的白板上。

贴领域事件——什么是领域事件(Domain Event)?

在系统中真实发生,需要被记录的事件(大数据的同学,请不要说话!),且会对系统做出反应。需要被记录的事件也就意味着需要被追溯。举个例子:电商系统中产生了一笔交易,同时对买家的积分进行了增加。增加积分的事件则需要被记录,而不是单纯的对分数进行修改。当用户希望知道我的积分都去哪了,我们就可以将这些事件进行追溯。

大数据的同学会认为所有的事件都应该被记录,为什么不让说话???并不是对大数据同学的歧视,大数据并不属于业务系统,而是横切所有系统。

领域事件

用橙色的便利贴表示领域事件,使用 名词 + 动词过去式,例如:订单已创建。通常以XX 已 XXX。

在带有时间轴的白板上贴上我们刚刚写好的事件,你认为在事件轴上的任意位置。以这张卡为参照,相继贴上在这张卡之前和之后的事件。

此时可以让每人轮流读出自己写好的卡片,并贴到白板上。如果参与的人数过多可以根据事件前后和参与人数进行分组。在贴卡的过程中,领域专家和组织者可以回答大家的业务问题,以及纠正卡片的错误。

最后,领域专家要带领大家将贴好的卡片进行梳理,剔除重复的卡片,删除在业务系统中不存在的事件等等。在梳理的过程中会发现很多意想不到的卡片,我们后面再讲。

贴Policy——什么是Policy?

Policy 不太好翻译,翻译成“政策”有一点点奇怪, 是在较新的资料中才有,我们可以理解为规则。

在一些业务设计过程中会有很多的规则,这些规则通常不能被建模工具有效的方式表示,都变成了“潜规则”。例如:

用户输错3次密码之后需要锁定账户。

输错3次密码 就是我们的 Policy,锁定账户则是 Policy 触发的新领域事件。

Policy

用紫色的便利贴表示 Policy 。

贴命令——什么是命令(Command)?

事件贴完了,接下来我们可开始贴命令。我们需要探索用户如何与我们的系统进行交互,命令代表着用户与系统的交互,而事件则是发生交互之后所产生的。

命令

用蓝色的卡片表示命令。与 CQRS(Command Query Responsibility Segregation)的Command 含义相同。

PS: 由于命令* 与 领域事件 大部分是可以一一对应,为节省时间,可以在workshop 中适当省略。*

贴读模型——什么是读模型(Read Model)

在写领域事件的过程中出现了这样一张卡:

奇怪的领域事件

首先,我们需要先确认这张卡是否真的有这样的业务。买家是否有一个功能是可以看到自己所浏览过的商品列表?通常浏览列表不会被记录,记录的往往是商品详情,可能会有一个【最近浏览的商品】的功能与之对应,那么我们可以这样写:

商品浏览已收录

有同学可能会说,我就是想标记出买家所看到的东西,有什么卡片可以帮助我们吗?这就是——读模型

读模型与 Policy 都是较新的资料才出现的。是表示用户所看到的东西,之后用户会发出命令。

读模型

用浅绿色来表示读模型。与 CQRS 的 Query 含义相同。

贴角色(role)

角色是系统中必不可少的,我们可以轻易的识别出这一系列卡片由哪个角色触发。

角色

用黄色表示角色。

贴到这里可以看出墙上的卡片已经可以连成一句话:【买家】在【查看购物车列表】后【提交订单】完成【订单已创建】,与我们写的用户故事越来越接近。

贴外部系统(External System)

在开发系统时多多少少都会与外部系统做集成,例如:支付系统、短信系统等等。我们通过浅粉色的卡片将外部系统表示出来。

外部系统

划分子域(Sub Domain)

啥是业务子域?我们得先了解一下什么是领域(在文中下方有对领域的解释)。

领域:在文中提到了大量的“领域” ,在没有了解过 DDD 的同学肯定晕菜了。我们先来看看书上是怎么说的:

领域(Domain)即是一个组织所做的事情以及其中所包含的一切。... 每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。

——《实现领域驱动设计》

我们可以单纯的理解为 “整个业务” ,为什么不直接说 “业务” 呢?业务的含义过于广泛,而且一点都不神秘,不够酷!

为分解领域的复杂度,将领域划分为若干个子领。

就好比一个庞大的复杂设备是由千万个部件组成,而每一个部件又是由千万个零件组成。其目的是为了降低单个部件的复杂度,只需要将复杂构造和逻辑封装到部件内部,对外暴露出简单的接口即可。

子域理解起来相对容易,但想要合理的划分起来却非常困难,需要对这个子域中发生的所有事件划到一个 Scope 中,在探索的阶段我们可以暂时将事件的名词提炼出来,作为我们子域。

划分子域

PS:子域的划分正确并不容易,在项目初期并不建议过细粒度的划分,需要等业务边界足够稳定我们再将其划分。

到这一步我们已经完成了对业务全景图的探索,下面我们来玩一些更有趣的卡片。

贴警告信息(Hot spot)

现在我要给每个人手里发一把“大锤”,找出系统中你认为可能出现问题的“钉子”,用深粉标记出来。我们站在挑刺的角度可以发现系统中可能出现的很多问题,程序员尤其擅长这一点。当然,这里的“问题”不仅仅是开发时的问题,也可以是业务问题,或是流程问题,外部系统的问题。

警告信息

投票评选瓶颈(Bottleneck)

既然选出了“热点问题”,接下来我们来给这些问题进行投票,找出我们需要优先解决的问题。每人一票(可根据情况适当增加),使用画有箭头的蓝色便利贴表示。

投票评选瓶颈

贴新的商机或者价值(Opportunity)

现在我要重新发给每一个一把新的“大锤”,找出我们系统中可能存在的商机或者价值。例如:我们是否可以提供 Plus 会员服务,是否在充值的基础上提供金融服务等等…使用绿色的便利贴表示。

新的商机或者价值

其他有趣的元素

这些卡片并非一成不变,我们可以根据自己的需求给卡片加上图标,赋予便签特殊的含义。例如:定时任务、调度程序等等...

其他有趣的元素

总结

以上就是我们今天所产出的所有内容,这些卡片可以帮助产品经理轻易的编写“用户故事”,同时还可以帮助开发人员业务建模,如果采用响应式编程(Reactive Programming)作为编程模型就可以将产出直接翻译成代码。

有参与过其他 Event Storming Workshop 的同学可能会发现与以往的不太一样。的确,Workshop 只是一种手段,Event Storming 做为建模工具也并非一成不变,卡片的颜色、顺序、多少可能不尽相同,只要为我们达到想要的目的就是好工具,不必要一定相同。

Workshop 的过程不仅仅是出贴便签,还希望我们在贴便签过程更多的沟通。帮助参与者达到快速统一的理解。也希望大家能够在内部多组织这样的活动,谢谢!

上一篇下一篇

猜你喜欢

热点阅读