DDD之事件风暴-领域事件分析-技术圈

使用事件风暴是一种很好的开始，在整个过程中尽量的把相关涉及人员配齐，包括领域专家、架构师、产品经理、开发、测试等。领域建模是统一团队语言的过程，因此项目团队应尽早地参与到领域建模中，这样才能高效建立起团队的通用语言。到了微服务建设时，领域模型也更容易和系统架构保持一致。

事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文。

准备阶段

在真正进行事件风暴之前应该把项目初衷或者说是问题域明确，即使同步相关参与人员。提前准备一些不同颜色的贴纸，为在后续发散过程中可通过不同颜色的贴纸将领域行为细分为命令、实体、领域事件、补充信息等。

开始阶段

领域建模的过程主要包括产品愿景（明确问题域）、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。

明确问题域及产品愿景

在建模之前，项目团队要围绕以下两点来思考：

1、统一网关平台到底能够做什么？

2、它的业务范围、目标用户、核心价值和愿景，与其它同类产品的差异和优势在哪里？

当前接入渠道由各业务方分散管理，对于接入渠道的复用性和证书管理都是一个极大的挑战。同时，各业务方独立维护接入渠道，对于知识共享存在一定的割裂，没有一个长期统一的知识沉淀。不规范的管理、较差的复用性以及较高的接入成本是当前接入渠道所面临的主要挑战，针对以上问题规划统一网关平台用于应对，该平台应实现以下服务能力：

统一渠道接入通用能力，提供统一加解密/加延签、报文组装等通用功能。
集中管理证书，避免分散治理带来的高运维成本。
支付渠道隔离，渠道之间互不影响。
渠道流量控制，根据策略动态调整各支付渠道交易流量（例如：微信渠道A机房：B机房=1:1）。
明确业务身份，实现多租户指定渠道复用能力。
实现热部署机制，降低故障渠道运维成本。

事件场景分析

场景分析是从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模。事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。

总结：

事件场景分析是一个很核心的环节，这一过程是所有项目参与者共同梳理项目业务能力细节的过程，是所有人达成业务共识的关键环节。该环节的讨论会涉及到一些业务的具体实现，根据具体的实现来验证业务事件的可行性，此处需要注意这里说的具体实现并不是指技术实现细节，而是指相关系统的业务实现。往往有时在讨论细节时，会有人认为这些细节是技术实现认为应该到战术设计阶段去设计，战略阶段不讨论具体实现细节。这个思路本身没问题，但是有问题的是我们讨论应该围绕的是业务实现而不是技术代码层面的实现。事件分析要细、要深，该环节讨论的越细、越深大家理解的越透彻，避免因为此处讨论的粗糙导致后面推翻事件的情况，这样影响会很大，因为后面的提取实体、领域划分都是依赖大家对事件的分析理解而实现的，有着承上启下的能力。比如：在该环节需要讨论业务码映射的配置、应用接口调用入参，如果提升用户操作体验，这些都深入讨论有明确的结论，不能因为感觉上这些讨论点设计到了技术实现，就粗略的过滤一遍，下沉到后面的战术设计阶段去讨论。

1、事件场景分析涉及三个元素，命令、业务流和事件。命令和事件是最终的产出，因为要根据两个元素提取实体，那业务流是什么呢？理解业务流有两种极端思想，一种认为业务流是这个环节的核心，重要程度很高；另一种认为业务流业务流只是一种描述，重要程度很低：

重要：通常这种思路是要现有业务流，然后再分析应该有哪些命令和事件，业务流相当一种功能场景。
不重要：业务流可有可无，只不过是命令和事件过程中的一段描述，淡化业务流存在的意义，最终产出也没它啥事。

2、列出的命令要有明确的含义，要知道其背后所代表的业务能力，要确定是一个可被执行的有效业务动作。命令和事件是多对多的关系。通常命令是以动词开开头+意图描述，例如：创建用户、查询权限等；而事件是以名词开通+意图描述，例如：完成用户创建、实现权限校验等。

3、讨论过程中，参与人员要避免提一些没有想好讨论的问题，避免那种突然想出一个场景，然后开始一顿描述，最后自己都说不清楚要讨论什么，只能来一句“先这样吧，以后再说”。这是一种很低效的情况，我们可以接受那种没有想好结果或实现的问题，但不要有那种没有论点的问题。

4、分析过程中要有争论，只有互相争论才不会被一个人的思路带着走，这一阶段要集思广益。当然争论之后只能有一个明确的结果，对于结果一旦确认，应达成共识。避免一些无用或没有意义的争论，比如：A认为这个命令应该叫做创建用户，B认为应该叫做新建用户，针对这种两可的答案，建议一方妥协，不需要再这种问题争论上浪费时间，降低效率。妥协方也不要因为没有按照自己的节奏而产生抵触。

5、对自己的产出要有较高要求，无论是命令、业务流还是事件，都要尽量精短、准确，描述文字不要太多。比如：验证对方接口调用能力可以抽象为接口鉴权，报文加解密/加延签可以抽象为身份认证等。另外在整个分析过程中要统一描述用语，不要存在前后多称呼的情况，报文组装、报文拼装、通道能力、渠道能力，无论叫什么，只要统一达成共识就好。

6、事件场景分析建议做三轮：

第一轮：事件发散，列出全量的事件场景。
第二轮：去伪存真，过滤掉没有真实用途的事件，也就是拿掉伪需求，但是对于一些当前不存在但后续是可扩展的事件建议保留。
第三轮：达成共识，强制统一讨论结果。主要是为了解决在前两轮讨论过程中，参与者还存在各存己见的场景或是前两轮参与者不全，部分参与者对事件了解有遗漏的场景。

提炼事件场景分析的三个核心关键词：细、共识、全员。

细：这一阶段要把业务分析透彻，所有事件具体实现均需讨论到。为后续的实体提取和领域划分打基础。
共识：无论分析过程中讨论的情况如何，但是对对于最终的结论要达成共识。
全员：这一阶段无论是对产品、开发、测试、领域专家还是架构师来说都很重要，参与的人员要全，能避免后面出现一些重复问题或者战术设计偏差的情况。