模型探索漩涡

《领域驱动设计15年》第17章

译者：张涛

校审：杨琛、伍斌

运用事件风暴和实例地图

1. 介绍

人们经常想要得到关于模型探索更具体的指导，尤其是在敏捷或精益的环境当中。而模型探索漩涡，就是Eric Evans^[1]尝试以书面形式给出的指导。虽不是一个开发过程，但它却是一个适用于大多数开发过程的过程。该过程的核心主题，就是持续挑战已有的模型。尽管该过程本身在大体上简单明了，但对如何进行这样一个模型探索漩涡，是没有太多具体实例的。大多数人在开始使用DDD（领域驱动设计）时，都在寻找这样的实例。本文将介绍我使用模型探索漩涡的故事，其中涉及来自DDD社区的“事件风暴”技术，和来自BDD（行为驱动开发）社区的“实例地图”技术。

2. 收获和记录

模型探索始于收获和记录（harvest & docment）当前状态。如果正在启动一个新项目而没有当前状态，那也不必担心，下面很快就会谈到解决之道。该阶段的主要目标是收集参考场景，捕获模型的点点滴滴，然后留下大多数想法。该阶段的起点可以是以下几种：根据来自事件风暴的全景图而形成的约束；一个新项目；或者只是待办列表中的某个用户故事。只要能有个故事可讲，就是一个好起点。

事件风暴是我最喜欢使用的工具，能帮你灵活地通过多人协作来探索复杂业务领域。在短短几个小时内，就能收获并记录大量的知识。这个阶段的成功要素，是要邀请到合适的人选来参加事件风暴。这些人是了解领域的领域专家。我们希望尽可能做到包容，但也会有例外。下面这些都是至关重要的——创造一个能让知识自由流动的安全环境；有一个能创造奇迹的出色引导者。当然除了这些，还需要满足一些限定条件，比如某举止欠佳的人，会扼杀一个富有成效的工作坊，所以或许要考虑将其排除在外。但也许此人拥有此阶段必不可少的领域知识。因而在这个阶段，在工作坊之前就与此人沟通是个明智的选择。在沟通时可以看看是否可以从他那里获得一些信息，当然更好的办法是改变此人举止欠佳的行为，以便让他可以加入工作坊，但这往往很难。

2.1. 工作坊

对于举办工作坊来说，重要的是能找到一个足够大的建模空间，最好空间能无限大（如果有的话！）。我一般会找至少有8米长墙壁的房间，然后在墙上帖上一卷白纸。房间当然还需要有一块白板。接着就可以进行“事件风暴”，来捕获领域的当前状态了。我们会给所有参与者橙色便签和记号笔，然后要求他们写下领域事件。领域事件是后来Eric Evans在DDD参考书里新增的一种模式。简而言之，领域事件指在领域中所发生的与业务相关的事件。在事件风暴过程中，我们希望能够捕获当前状态下的领域事件，并按时间顺序将其帖在白纸上。在此过程中出现混乱在所难免，所以要管理好大家的期望，并且要向大家解释，最终会将此过程的产出结构化。

2.2. 讲故事

当每个人写出自己的领域事件后，就该讲故事了。要让参与者在强化时间先后顺序的基础上，保持故事的一致性。在去除重复事件时，要确保真的出现了重复。因为经常会出现两个被认为是相同的领域事件，实际上却是不同的。在这个过程中，故事要保持足够的细致和具体。此时要尽力发掘专家们的不同意见，并用醒目的粉色便利贴将这些热点标识出来，从而即使在远处也能轻松辨认。

2.3. 将隐性的事物显性化

像事件风暴这样的可视化会议的核心，是我们仅讨论用便利贴显性化和可视化出来的事物。我们可以从领域事件以及热点中，捕获如此多的知识。而如果捕获了更多类型的知识，则可以用其他颜色的便利贴标识出来。标准的事件风暴便利贴颜色包括（也可以使用能找到的其他颜色）：

蓝色：动作/命令
粉色长条：(外部）系统
紫色长条：策略/最终的业务约束
绿色：信息

（有关事件风暴的更多信息，请阅读Alberto Brandolini的书）

虽然事件风暴的基本流程看起来就这些，但是其中的关键点是要让交流显性化。如果房间里的每个人都能做到交流显性化，那就足够好了。如果无法确定能否做到这点，那么就试着按照这个流程去做。记住，要将隐性的事物显性化。那些没有体现在墙壁纸卷上的讨论，都需要将其显性化出来。有时很难仅通过几个便利贴就能将事物显性化出来，这也就是为何手边需要有一块白板，以便绘制草图和示意图，并写下模型的方方面面。

2.4. 偏差盲点

至此故事已经讲完，下面要引入实例地图。大多数情况下，人们会认为再引入另外一种工具很浪费。不是已经将故事可视化出来了吗？不是已经得到完整的故事了吗？问题在于，每个人都会受认知偏差的影响，特别是当获得过量信息的时候。我们会注意那些已经存在于记忆中，或经常会被重复提及的事情，这被称为情景效应和注意力偏差。那些能证实我们自己已有信念的细节，也会吸引我们，这被称为观察者效应和确认偏差。而相比发现自身缺陷，我们更容易发现别人的缺陷。在进行领域探索时，这种偏差盲点特别危险。为了纠正这些偏差，需要听取不同的观点，或者使用其他工具。

因为能聚焦于特定的实例，实例地图这个工具此时就能帮助我们。要运用这个工具，需要在相关模型的附近找出一个空间，比如事件风暴旁边或单独的一个纸卷。可以使用下面的方法来开启事件风暴——用美国情景喜剧《老友记》剧集名称的风格，在便利贴（通常是绿色的）上写下实例。《老友记》每集的名称，都是以该集的核心情节来命名。然后跳出思维定势，看看这些实例会在哪里影响当前的事件风暴。当前系统是否存在缺陷？当前知识是否存在空白？对于这些障碍，可以用热点进行标记，并使之显性化！

此时，房间里所有参加工作坊的人们，可能已经收获到了有关当前状态的足够多的洞见。现在，我们可以隐隐看到浮现出来的限界上下文，或者看到几个系统彼此纠缠的地方，以及并没有显性化的边界。上面所描述的工作坊的第一部分，总共需要大约2～3个小时，相比所获取的大量知识来说，这只是一笔很小的投入。当我们对现状进行如此多的知识消化之后，明智的选择是离开工作坊，好好休息一晚，然后再处理所获取到的知识。

3. 场景

在获得了现有系统所有的知识之后，我们希望针对未来的系统做同样的工作坊。对于未来的系统，需要创建一个新的建模空间，以便再次进行事件风暴，并使用新的纸卷，对未来状态的领域事件进行事件风暴。

3.1. 推演并重点关注难点

一旦完成全部的事件风暴，就要与往常一样，推演一遍所有事件，重点强化时间线，并删除重复的领域事件。此时要重新关注难点，挖掘出其中的复杂性。为此，我们可以引入一个新概念。这次不是使用粉色长条便利贴，而是使用黄色长条便利贴来表示一致的业务规则。相比在一张便利贴上写多个业务规则，每张便利贴只写一个，将有助于稍后更有效地对其进行重构。每个领域事件之前，总会有一个一致的业务规则。

首先需要寻找一致的和最终一致的业务规则（黄色和紫色长条便利贴），并专注于这些部分。通过添加其他颜色的便利贴，使故事保持一致。要关注所使用的语言，最要紧的是要寻找和分析词语在哪里出现了歧义。此外，还要开始添加角色（actor），使得谁负责故事的哪个部分变得明确。所有这些信息结合在一起，就可以定义出适当的界限上下文。

3.2. 实例地图

与之前分析现有系统的实例地图一样，我们在分析未来系统时会再次使用实例地图。首先从事件风暴部分开始，将实例写在绿色便利贴上，并贴在事件风暴旁边，或单独一面墙的另一张纸卷上。下面会详细描述实例地图的做法，即针对每个业务规则，垂直地贴一列实例便利贴。并在该列顶端，将业务规则写在一张蓝色便利贴上。此时重要的是，每个垂直列，仅有一个业务规则。这意味着某个特定的实例可以多次发生，但每次发生仅针对一个不同的业务规则。