后端 事件风暴工作坊初体验

https://www.dazhuanlan.com/wx770812562/topics/1170840

 

 

 

 

本月有幸参加 DDD 中国在广州举办的【微服务时代的领域驱动设计实战工作坊——广州站】，在参加之前就好奇，什么叫做工作坊？
一天的活动下来之后，对工作坊的工作方式有了初步的体验，我尝试把它写下来。

 

什么是 DDD？

实战工作坊的核心理念是基于 DDD（领域驱动设计）的，它本身并不是什么新理念，
早在十几年前由 Eric Evans 在《领域驱动设计》提出来。

软件设计发展历程中，首先是面向过程设计、然后再是面向对象设计（OO）。
简单的业务用面向过程的方式实现是没毛病的，但是遇到复杂的业务逻辑的时候，面向过程就有心无力了。
所以有了面向对象的设计，封装、继承、多态是 OO 的基本理念，大多数实现 OO 的语言都有的特性。

但是，知道什么是 OO 并不等于知道如何去做到 OO，有没有什么套路让我们更加有效去实现一个 OO 的设计呢？
答案就是 DDD，DDD 给予我们设计 OO 的方向，它解决的核心问题是业务架构与系统架构如何去保持一致。

 

领域驱动设计是一种设计方法, 试图解决的问题是软件的难以理解, 难以演化. 领域驱动设计试图
分离技术实现的复杂性, 用围绕业务概念来构建领域模型的方式来控制业务的复杂性。

DDD 三原则

• 关注核心域
• 通过协助迭代探索模型
• 在同个限界上下文内使用通用语言

什么是事件风暴？

实现 DDD 的方式也是多样的，事件风暴是其中的一种。它是由 Alberto Brandolini 所创建的一种专注于事件的设计过程。

事件风暴就是把所有的关键参与者都召集到一个很宽敞的屋子里来开会，并且使用便利贴来描述系统中发生的事情。
一张桔黄色的便利贴代表一个领域事件，在上面用一句过去时的话描述曾经发生过什么事情。
为了让自己关注最终目标，经常从结束时的最后一个事件开始，然后把第一个事件加上来，就有了一个从开始到结束的完整时间表。

 

 

 

工作坊给了我们一个贴近实际的业务场景，让我们按照事件风暴的实践步骤，从事件的角度，一步步去设计业务模型。
经历过一天的切身体会，事件风暴是一种简单高效的建模方式，它没有 UML 那么复杂的条条框框，
也能让非技术的关键业务角色参与进来核心架构的设计过程之中，从而让系统架构和业务架构高度一致。

 

事件风暴实践步骤

事件风暴的实践步骤主要有以下 4 点：

 

 

 

 

事件风暴

事件风暴的概念是来自于头脑风暴

首先需要把项目相关的所有关键参与者都召集到一个很宽敞的屋子里来开会。

业务专家先介绍核心业务与主要的业务场景，参与者参与讨论。

参与者按照自己对业务的理解，寻找业务过程中发生过有业务价值的事件，写在橙色的即时贴上。
（一个事件一个即时贴，采用 “xx 已 xx” 的格式，比如” 订单已创建” ）

每个参与者把自己的事件贴到白版上，最后按照事件时间顺序从左到右排序，去重。

 

命令风暴

事件是由某些决策产生的命令触发的。决策的类型有 3 种：用户指令、外部系统触发、定时任务。

从已发现的事件里倒推出相关的命令，把发出命令的决策写在蓝色的即时贴上。
决策贴在事件的左边，有些决策可能触发多个事件。

从决策出发，发现决策参考的读模型（紫色即时贴）、和触发决策的角色（黄色即时贴）。

 

 

 

整个流程下来，基本上所有关键的业务事件、角色、决策都可视化了。

 

寻找聚合

从命令风暴的结果里寻找聚合（用大的黄色即时贴），保留相关的决策和事件。

划出边界，找出限界上下文。上下文之间建立地图，用 U／D 标出上游／下游的关系。

 

 

 

 

持续探索

持续讨论，演进上下文映射图。
从上下文出发，自然而然的做到微服务划分。

结论

通过工作坊的方式，可以产生很多有价值的领域模型。

微服务如何划分一直是个难点，从事件风暴出发直到画出限界上下文，服务划分自然而然。

从事件的模型出发，去实现 EDA 和 CQRS 架构也有了很好的起步了。