利用事件风暴发现限界上下文(下篇)——《领域驱动设计15年》第三章

利用事件风暴发现限界上下文(下篇)——《领域驱动设计15年》第三章

4.5. 第5步 明确的串讲

事件流中的每一步,都要做一些澄清,从而需要编写更多的事件。即使我们添加了像关键事件和泳道这样的结构,并在现场进行了一些有趣的对话,系统整体仍然让人感到混乱。这可能是因为事情本身就很乱。

现在到了验证我们发现的时候了。挑选一位讲述者从左到右讲述整个故事。一开始,讲述者很难将故事连贯地讲下来,因为其思路会被相互冲突的需求打乱。讲述者会试图用现有的事件来讲述故事,但与此同时,又会意识到,在之前的讨论中所形成的足够好的内容,一旦搬到舞台上却形成不了一个好故事。

此时,为了把故事讲好,需要改进模型,创建更多事件,去除不必要的事件,分割一些路径,诸如此类。

其间,观众不应该被动地观望,而需要经常挑战讲述者和其讲故事的方式,最终提供一些特殊情况和常见意外的案例。

我们在时间轴上串讲得越多,流程就越清晰。而讲述者就像一个磁盘去碎片化的游标[1]一样,在向右推进。

图“用明确的串讲来对理解进行验证”

4.6. 第6步 额外的步骤

现在可以执行一些额外的步骤,这通常取决于上下文。这些步骤可以带来更多洞见,简述如下。

  • 可以研究业务流中期望产生出来或不幸遭到破坏的价值。而价值需要不同的方式来度量——钱是最明显的度量方式。而其他人对另一些度量方式更感兴趣(比如时间名誉安全感压力幸福等等)。
  • 可以探索现有流程中的问题机会 ,允许每个人提出之前没有涉及的问题,或者公布改进的想法。
  • 可以用可选流程挑战现状。当确定了对当前情况的理解,此时对其更改会发生什么?哪些部分将保持不变,哪些部分将被彻底改变或摒弃?
  • 可以投票选出最重要的议题,将集体理解的明确性,转化为行动势能,以做正确的事情。[2]

所有这些额外步骤,能带来很大帮助!如果仔细观察,就会发现绘制上下文边界所需的大部分信息,都已经触手可及了。

软件架构师的工作,就是从工作坊中获得上述信息。

5. 作业时间

一旦工作坊正式结束,参加者离开了工作坊,就可以开始讨论软件了。这一刻终于到了!

我过去常常画上下文图,作为强迫自己在项目早期问出正确问题的一种方法。但现在,我搞事件风暴工作坊,让干系人参与并直接提供正确的答案,而无需我来提出相应的问题。

上面步骤的讨论,能产生很多与界限上下文相关的信息。此时只需要研究这些线索就好了。所以,下面这些启发式[3]的活动,会派上用场。

5.1. 启发:观察各个业务阶段

观察各个业务阶段,就像侦探常说的那样:“顺着资金流动找线索!” 业务通常围绕着一个定义明确的交易而展开,而其中的价值(通常是金钱)会被交换为其他东西。关键事件在这个流程中起着根本作用:如果没有网站,就无法在线销售门票。而在网站上线之前所发生的一切,都仅仅是库存或成本。只有在会议网站已上线这一事件发生后,才开始赚钱。

同样,在票已售事件之后,我们将成为参会者资金的临时所有者。但参会者们只有在会议已开始事件发生后,才能开始获得价值。不过,设计 会议所需的工具和心智模型,与运营会议所需的并不相同。

图“将关键事件放大”

有趣的是,描述边界事件的措辞,往往会发生冲突。这表明此处人们所感知的限界上下文发生了重叠。这里有一个重要建议,不必就语言达成一致意见! 因为通过暴露分歧,能发现更多内容。

此外,请记住,当两个模型进行交互时,通常会涉及三个模型:两个限界上下文的内部模型,以及用于在它们之间交换信息的通信模型

图“两个相互作用的模型通常意味着三种语言”

一个简单的例子:我尝试使用英语与读者沟通,但我的母语不是英语。我的心智模型有时是英语,有时却是意大利语。但这一点读者应该识别不出来(我希望如此)。同样,本文不仅适用于英国和美国人,每个读者都可以用他们的母语翻译成他们的心智模型。

一般来说,不同的阶段通常意味着不同的问题,这通常会导致不同的模型。

关键事件通常是各方之间所共享的更为通用的发布语言的一部分。

图“在全景事件风暴之后所浮现出的限界上下文”

上面的图片或多或少地显示了,当我以限界上下文的视角看待流程时所见到的内容。

5.2. 启发:观察各个泳道

泳道通常可以显示不同路径,其中涉及不同模型。

泳道并不都会与限界上下文一一对应,有时泳道只是某个限界上下文中的 if 语句。但是当为了突出一个独立的过程而浮现出一个泳道(或许在不同的时间线上) ,那么就可以将其当作一个独立的模型。

图“在划分不同限界上下文时,泳道通常是可靠的线索”

5.3. 启发:观察纸卷上的各种角色

当处理不同的角色时,会发生有趣的变化。显然,一个流程对于不同角色应该是相同的,但事实往往并非如此。

会议组织者或专题出品人可以邀请一些演讲者,而其他演讲者则在论文征集中提交他们的话题。在上游,不同角色的过程流可以独立出来(比如明星演讲者可以跳过繁琐的评审过程)。而在下游,则要以相同的方式处理(比如无论哪种演讲者,其会议日程的数据应该一视同仁)。

图“两个并行过程流可能需要相互独立的模型”

有些组织能够很好地以角色的视角来思考:他们认识到在过程流的左侧,演讲者和主旨演讲者是不同的。但两种演讲者在注册流程中会得到相似的胸卡,并且在中午会和普通参会者一样去用餐,那时他们的角色将会是一个简单的mouth to feed。

5.4. 启发:观察屋子里的人们

这一点太显而易见,以至于都不好意思说出来,那就是:人。人们在探索过程中,能给出关于不同模型分布的最简单和最有力的线索。

领域专家们倾向于把大部分时间花在他们更了解的区域,要么解疑答惑,要么纠正纸卷上所发现的错误的便利贴[4]。或者,他们围绕着自己所关心的区域高谈阔论,这可能是因为当前的实现确实差强人意。

不同的人有着不同的需求,这意味着不同的模型。

有意思的是,人们在事件风暴中所逗留的位置,从来都不会被白纸黑字地记录下来,但奇怪的是这些往往会被其他人记住。

5.5. 启发:观察肢体语言

肢体语言是另一种信息来源:并不是所有的异议都是通过语言来表达的。表面上看是同一个问题,但来自公司不同层级的人有着不同的看法,这种情况屡见不鲜。摇头或着翻白眼,都预示观点冲突尚未解决。

领域驱动设计有一个绝妙的办法来解决这些冲突:不要说“我们需要一个模型来处理这些事项”,而是说“我们需要一个模型来解决你的问题,同时还需要一个模型来解决老板的问题”。完美的交流方式得靠软件架构师去发掘。

再强调一次:不同的需求意味着不同的模型。

事情还没有结束。下图描绘的当讨论关键事件或边界事件时,典型的对话模式是怎样的。

图“一次典型需求冲突,左边的人很了解关键事件所涉及的机制,而右边的只关心关键事件的成效”

完成一件事情,会涉及很复杂的知识。这些知识就像是一张任务清单。而在关键事件的下游,这种复杂性应该会消失殆尽——因为人们通常不关心过程,而只关心结果

在我们的场景中,情况可能是这样:“我不关心是不是用WordPress来发布网站,而只需要知道 URL 是不是可以访问。”或者“我不关心这些定价是如何决定的,而只想知道每一种票的定价是多少

5.6. 启发:倾听真实的语言

这可能是最难掌握的技巧,因为语言会欺骗你。几十年来,语言一直在愚弄我们,这也是领域驱动设计之所以存在的原因。

如果探讨像Talk这样的核心术语,你会发现它们会被用在许多不同的地方。

  • Talk可以在论文征集的过程中提交,接受或者拒绝。
  • Talk可以安排到指定分会场的特定时间段之中。
  • Talk可以分配给指定的主持人或工作人员,由他们来介绍演讲者。
  • Talk可以由参会者评分。
  • Talk可以被拍摄并记录下来。
  • Talk可以发布在会议的YouTube频道上。

你确定上面所说的是同一个Talk吗?

这里的关键是,愚弄我们的通常是名词。人们总是倾向于观察事物的静态数据结构,来对其名称达成一致,比如:“Talk有一个标题”,这是很简单的一句话,非常容易达成一致,但这并不能说明我们实际上谈论的是同一件事。

就上面列表里的Talk来说,我们谈论的是不同的模型:选题议程人员安排等等。虽然这些模型具有同样的名字,也需要一些共同的数据,但是它们之间是不一样的!

然而,当围绕一个特定的目的动词能提供更强的一致性。

6. 荟萃一堂

相比传统和正式的需求收集活动,通过事件风暴工作坊所获得的信息的数量,具有大规模压倒性的优势

人们的行为和肢体语言,不合适用标准的文档记录下来。然而,这种非正式的信息,往往能引导人们找到良好的模型,因为……我们说过,并且做过!像只围绕各自的问题分别采取行动,只因为名字碰巧一样就将不同的事情混为一谈这样的蠢事,以后就不再发生了!

此时用不着太多的纪律或规则。因为把不该搞混的东西搅和在一起,这太愚蠢。它们在墙上差着老远呢!

希望上面所描述的这些启发,能有助于勾勒模型。但其中更重要的是,在做正确的事的强烈感召下,这些启发提供了一个良机,来理解软件的深层目的,甚至是理解组织的深层目的。

整个思路其实很简单,可以用一句话来概括:

汇聚人员,拆分软件

回顾过去,扪心自问:为何浪费这么多年,南辕北辙?


作者:Alberto Brandolini

作者简介:Alberto Brandolini也被称为ziobrando,是Event Storming的发明者,他还是意大利领域驱动设计社区和意大利Stoos Satellite的创始人,并积极参与有关敏捷软件开发,精益管理以及创业和协作的新方法的研究。作为行业享有盛名的大咖,Alberto Brandolini行事低调,对工作热情饱满,多次受邀作为嘉宾出席各类技术大会。2017年12月08日, Alberto Brandolini受邀参加了由ThoughtWorks在北京主办的《领域驱动设计峰会 2017》,并发表了精彩演讲。

译者:ThoughtWorks咨询师 覃宇、黄雨青、徐培、伍斌

参考

  1. ^如果岁数已经足够老,就能知道以前的磁盘碎片整理。
  2. ^这个领域可能就是核心域。
  3. ^我在这里使用“启发式”这个词,只是为了让Mathias Verraes高兴。
  4. ^没人禁得住这种诱惑:“有人犯错了!我必须马上指出来!”事件风暴利用了人类这种本能的行为,并将其变成促进建模活动的推进器。
发布于 2019-07-29

文章被以下专栏收录