事件风暴建模101

之前文章提到了对项目中使用MongoDB的思考，里面写了一些由于数据库导致了项目中领域模型设计的问题，有必要采用DDD的方法和相关实践对项目进行领域建模和梳理。马上，下个月要去客户现场做工作坊，如何设计好工作坊, 通过良好的引导帮助我们与客户顺畅协作，全面地梳理业务概念，并基于业务概念进行抽象和聚合，完成领域建模和域划分是这次工作坊的主要内容之一。那么在去之前，很有必要回顾一下事件风暴的建模方法论，为工作坊顺利完成做好准备。

什么是事件风暴？

EventStorming是一种用于复杂业务领域协作探索的灵活工作坊模式。它可以按照不同的形式开展，并适用于以下场景：

评估现有业务运行状况和发现有效提升业务状况的措施

探索新创业务模型的可行性

设想新的服务，最大限度地提高每个参与方的积极成果

帮助设计整洁可维护的事件驱动软件来支撑迅速发展的业务

事件风暴建模过程

通常事件风暴工作坊需要熟悉熟悉方法论的主持人引导，业务顾问和技术顾问以及客户熟悉业务的领域专家和熟悉系统的技术专家一起参与。工作坊在一个开放空间开展，需要有足够长的墙来贴上白纸方便所有参与者按业务的时间顺序贴上建模需要的关键信息，足够的便利贴和事件风暴建模方法中关键要点的指导说明。这些信息将作为领域建模的重要输入。

工作坊空间

工作坊由添加领域事件开始，领域事件一般用橘色的便利贴表示，书写领域实践的规则是使用被动语态，并按照时间顺序贴在白纸上。刚开始，一些参与者对具体怎么写事件便利贴还是会有疑惑，这时可以关注一些行动更快的参与者，将他们作为模板，这时其它参与者会迅速的开始模仿，这时我们可以让大家快速的进入状态。在大家的讨论中，我们也会发现大家可能也只了解局部，这个工作坊也是第一次将各个局部信息组织到一起，也有人描述出领域事件但是也不了解背后的细节，或者给出“流程总是阻塞在这里”之类的描述。这些信息也很关键，我们也需要将其记录下来，为我们全面了解业务模型提供更多的细节，通常我们用紫色的便利贴记录这类信息，并将其与领域实践关联起来。对于疑问和告警比较集中的领域事件，也会是后续需要重点优化的部分。

记录所有的警告、讨论和疑问

在工作坊中，我们会听到一些客户的领域/技术专家谈到某处，会发散开来提到一些很有洞见的观点和我们不曾预料到的领域复杂性，每当这些话题出现时，也会使用便于区分的便利贴来记录这些上下文。这些上下文不需要刨根问底，只需要准确的描述当时的对话中的内容即可。很多时候，这些对话会以开放式的问题结束，这也问后续进一步的讨论提供了方向。

随着我们对业务认识的不断加深，可以随时回顾和总结之前添加的内容，对于有问题的描述进行更正，对于表述不清楚的内容可以进行重写。

在收集完领域对象之后，我们可以进一步开始探索系统核心事件的运行机制。这时我们在之前的领域事件的基础上加入指令和角色的概念。指令代表系统中用户的意图、动作和决定，一般用蓝色的便利贴表示；角色表一类特定用户，一般用黄色便利贴表示。它们之间的关系是“角色”发送“指令”产生了“领域事件”（指令也可由外部系统触发，外部系统通常用粉色的便利贴表示）。

用户发送指令产生领域事件

在加入指令和角色后，会触发更多关于为什么用户会产生这个操作的讨论。关于指令和角色有意思的是，指令作为用户决定的结果，当我们在思考是什么原因导致用户做这个决定时，我们会产生类似“能让用户更容易的作出决定吗？”，“能帮助用户作出更好的决定吗？”的问题。这些问题将帮助我们思考与用户做决定相关的数据模型。这时，我们会将这类数据模型记录在绿色的便利贴上。

读模型-视图

更有意思的是，在探究用户作出决定的动机时，我们会发现同类型角色的用户并不相同。即使做出了相同的决定，背后的动机也会有很大区别。随着讨论的深入，我们会用一组更加贴切的用户画像来表示角色，这也帮助我们在构建MVP时更有效的捕获用户角色。随着我们更深入的了解领域事件的内部机制，我们也会越来越多的讨论到领域事件发生后引起的系统变化。这种变化通常通过“当...发生时...”的句式描述出来，比如“当用户通过新的设备登入时，系统会发送提醒通知”。通常，我们将这种系统的行为逻辑称为策略,通常记录在紫丁香色的便利贴上。

不论是手动或者自动的行为逻辑，都是系统策略

在一个将要新创建的系统中，越早捕获这些策略对构建系统越有利，因为它们可以帮我们避免依赖假设而实现系统。当我们收集完业务中相关的信息之后，这时也是业务中关键聚合涌现之时。我们把跟一个概念相同的指令和事件集合到一起，并用黄色的较大的便利贴表示:

现在我们有了事件，指令，角色，视图，策略和聚合的概念，它们之间的关系总结起来如下图的关系所示：

事件风暴中概念之间的关系t

事件风暴建模的技巧

在收集领域事件的过程中，由于参与方众多，一开始大家写的领域事件会比较发散，也有很多类似的描述。前期我们需要抑制内心想要统一它们的想法，因为不同的表达背后可能意味着大家不同的理解，我们可以做的是把相关的事件放在一起，一遍后续进一步分析。为了方便按照时间去组织, 我们可以在众多事件中，找到一些大家没有分歧的关键事件，然后给予关键事件来做参照，然后在关键事件标记的范围里，按照不同的组织和上下文来组织领域事件。

挑选关键事件

在对领域事件进行分类时，由于事件之间有不同的逻辑关系，可能需要对不同事件段内的事件进行分类。分组能让我们在排列时的逻辑更清晰，也方便我们对事件的上下文进行划分。最后，基于关键事件的领域事件分组会形成下图的结构：

基于关键事件的事件流

通过时间线，我们可以更好的与众多的业务人员和领域专家进行协同，发掘领域事件。但当我们寻找聚合时，由于聚合是对业务规则的封装，保证数据的一致性，它会跨越领域事件的时间线。

结语

事件风暴建模没有固定的过程，它是根据具体情况而裁减的。通过事件风暴建模方法，能更好的引导我们与业务人员和领域专家合作，通过激发他们发表不同的观点和协调他们之间的冲突，帮助我们了解复杂业务的全景，更准确的建立业务模型。建模方法中的概念有限，但是通过这些概念，怎么能更好的挖掘描绘出业务模型是需要在不断的实践中学习和提升的。