03｜事件风暴（上）：怎样和业务愉快地聊需求？

1.上诉场景，有一个非常关键的依赖，你有一个全知全能的PO。很遗憾这个依赖它并不可靠，大部分情况你可能无法在项目初期拥有这么一位PO。所以上诉事件风暴顺利沟通的场景它可能很难成立。 2.那怎么办？如果没有这么一位PO那我们就补位。那么问题就从与关键PO进行领域风暴编程了PO如何快速了解领域知识，沉淀认知概念。 3.那怎么做？ A.绘制干系人地图，通过与业务专家/客户项目负责人沟通，把当前参与领域活动所有的角色都定义出来。 B。与参与度最高的角色，一起梳理业务全景（第一次时间会比较长，需要尽量不遗漏），重心在提炼顶层关键业务阶段，和该角色在这个顶层业务阶段下的所有用户旅程（用户旅程要包含 绩效指标 耗时 频率 参与人数 痛点等多维数据）。 C.拿着这个顶层关键业务阶段去和相同角色的其他一线人员碰（这里有框架了，主要在确认认知准确性和挖掘遗漏点）。 D.拿着顶层关键业务阶段去和其他角色重复上诉 B、C两个步骤。刻画全角色的用户旅程，得到业务全景。 E.拿着业务全景去跟领导层沟通，汇报 + 达成共识。这个环节最主要的是识别出战略重心/关键目标。领域知识本身是没有偏向性的，企业的战略才有。做子域划分要定义核心域，这里的核心域定义和选择很大程度取决于领导层提供的战略方向/关键目标。 F.有了业务全景和关键目标，拿着这两件产物和业务专家过事件风暴。这样在事件风暴一开始就有框架和目标，最后事件流的产出，成效会好很多（因为一开始就有了边界和收敛的方向）。 到这里没PO补位PO的玩法就完了。接下来把后续工作步骤也补充下。 G.事件流本身聚焦在"关键写"流程，修改删除查询不会过多刻画。这么做的原因在于，事件流后续产出物是领域建模（我习惯四色建模），重心是识别关键模型、模型角色及模型间关联关系。这个阶段的模型产出是比较粗的粒度。 H.追加业务全景里面的删改查场景，进一步增加模型、丰富模型上的属性、调整模型类型。 I.拆分子领域（这里与建模其实是并行的，提取完业务知识和关键目标就可以做，这是问题空间的事情，而建模是解空间的事情。多数时候它们是交织开展的，虽然概念上做了区分，但现实里它们就是交织在一起的，相辅相成）。基于关键目标，确定阶段核心域。两条个人观点：战略会变核心域也会变；关注点在核心而不是边界。 J.将问题空间与解空间合并。把聚合按业务相关性分类到子域上。结合物理因素/复杂度/组织结构/安全/调用频率等等一系列因素圈限界上下文。

尝试用事件风暴的方式梳理了支付系统的领域事件，放在了共享白板上，欢迎一起来头脑风暴 https://boardmix.cn/app/editor/3ywv0CZURp_x5wm2IDm8pQ?inviteCode=kjG6ak

事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件。 企业落地过程中，往往把事件风暴和头脑风暴混为一谈。 领域专家可能并不专业，往往谁的“权利大”谁说了算。 团队活动，参与人不明确，干系人选择性参与会议，比较佛系。 业务建模不关我的事，业务已经很清楚了，怎么做能不能实现是你们的事。 DDD是啥我们并不关心，对我们没有价值，没有DDD我们也做到了上市企业。 。。。 DDD实践是一个工程问题，践行时也是一个过程，在过程中只开一两次对齐会议是解决不了领域建模问题的。如果从利他角度来讲，在这个过程中的不同阶段每个人都可以受益，但不是同时受益，有可能要先解决哪部分人先受益的问题。

思考题： 1. 修改删除之类的，有相关的业务才需要列出来，比如合同签订了就只能违约，不能修改和删除，那就只有一个合同已违约，修改和删除甚至创建都一样是技术术语，事件风暴最好用业务术语。技术术语 创建，修改，删除 业务术语 添加（录入） 签订 违约等 2. 个人不觉得事件风暴是一种产出物，事件风暴只能做中间产物，产出物可以用多种方式记录，比如偏业务的用户旅程地图、服务蓝图 偏技术的UML 领域模型（带业务规则），这些图里面相对事件风暴更好记录，如果强行用事件风暴，觉得便利贴不好维护，可以推荐一波 BeeArt https://www.beeart.com/ 在线白板

2w2h笔记 What Q1：什么是事件风暴？ 是一种通过协助完成需求梳理的方法。 Q2：除了事件风暴之外，还有什么方法也可以帮助梳理需求？ 用例，use case，传统需求梳理方法。 Why: Q1：为什么要使用事件风暴来做需求梳理？ 1、业务人员与开发人员之间会通过协助方式来完成，可以使双方对需求的理解达成一致、补充遗漏的需求。 2、辅助识别领域对象。 3、事件风暴是结果导向的思路来梳理需求，更容易把业务想清楚。（DDD大师的经验） How Q1：怎样进行事件风暴？ 1、识别领域事件。 2、识别命令。 3、识别领域事件和命令中的名词性概念。（领域模型的基础） 整个过程是一个动态协助的过程。 Q2：怎样进行“识别领域事件”？ 1、业务人员和开发人员双方写出自己理解的领域事件。 2、通过沟通、协助来迭代领域事件，明确业务规则，构建统一语言，最终达成一致的理解。 Q3：在识别领域事件中使用的关键概念有哪些？ 业务规则、统一语言、必然的事件和可选的事件、业务流程的名称。 Q4：什么是领域事件？ 业务过程中业务人员主要关注的业务结果。例如：项目管理过程中，客户已添加。 Q5：什么不是领域事件？ 1、技术事件不是领域事件。例如：数据库已插入。领域事件是业务角度的事件。 2、查询功能不能算领域事件。例如：客户信息已查询， How Good DDD常识 1、在DDD中的各种命名，一般优先使用约定俗成的业务术语。

有个问题请教老师，我在做事件风暴的时候，如果事件本身很简单，但是业务规则非常复杂，这种情况怎么去揭示复杂的业务规则呢？

对于思考题，以增加功能为主的领域事件，我觉得不需要列举修改和删除功能，一面冲淡了领域事件的聚焦。特别是对于修改和删除操作本身不复杂的领域事件，就更没有必要了；修改和删除所关联到的规则，可以在业务规则中说明。 业务规则可以从文字说明量化为领域事件的属性，或者是一对多、多对多之类的关系，采用代码来表达。

极客时间上的课程中，要数ThoughtWorks的各位老师讲课讲的深入浅出，钟老师，徐昊老师和郑晔老师都很厉害，我从中学到了很多 抓个虫：最后一幅图中有一个灰色便利贴：“只能在项目有小区内才能报工时”，应该是“只能在项目有效期内才能报工时”，编辑同志该打屁股，哈哈 思考题： 1. 如果修改和删除涉及重要的业务流程，我觉得应该列出来，但可以慢慢迭代，不必一次就思考的那么全； 2. 用实体便利贴确实不容易维护，可以建模完成后拍照，或者用一些工具比如draw.io画下来保存在电脑上，建模的时候投屏

最大的问题在于业务人员会按上述的领域事件跟开发聊么？ 他们不会认为加上“已”就是领域事件了，我们是学了DDD，业务人员并没有学，他们还是会用自己的术语。 第一步应该考虑业务人员实际会通过什么来描述需求，怎么描述？要不要教他们DDD，还是说就应用当前业务人员的术语来描述领域事件。 对事件的定义是什么，举个例子，刺客某日刺杀总统算不算一个事件？这个事件并不需要加上“已”才是事件。再举个例子，订单生成后要发送电子发票给客户，通常会说触发发送电子发票事件，这个事件可能尚未发生，但也是一个事件。 所以对于领域事件定义是什么，要素是什么？ 加了“已”之后，更像一个结果，一个状态。相比而言“添加客户”比“客户已添加”能更好的表达事件。

2 刷，再来留言，自己在团队实践过这个事件风暴，但不是协作方式，是我自己脑暴，根据产品 prd 来脑暴，然后脑暴一波再去找其他同事+产品 double check，不协作是因为他们不愿意做这个事