3.基于事件风暴的DDD
不过，对于如何可操作地实施DDD，业界有很多不同的探索，而其中事件风暴（Event Storming）是一种既经济又高效而且充满乐趣的方法，也被证明是一种可以快速探索复杂业务领域的方法。
事件风暴是一种战术阶段的设计方法，它自下而上地从微观的领域事件推演出战略层宏观的领域模型。它被业界戏称为“糊墙”，因为它会在一个房间的四面墙上糊满便利贴。它几乎没有学习曲线，唯一稍微有点高的要求是要有一间足够大的房间，并且有足够多的不同颜色的便利贴。它的核心是协同共创，要求领域专家、业务架构师与技术人员以协同的方式迭代地探索构建出领域模型。
事件风暴的理论基础来自领域事件。如果一个系统能够支持一项业务，那么当该业务开展时，角色在业务上的操作就会导致系统的响应，从而留下一些足迹。这些足迹往往以数据的形式存在于某个地方。留下这种足迹的系统的响应就是领域事件。通过对领域事件足迹的追踪可以推测当时的业务操作。如果把领域事件按照时间排序，就能在时间线上还原一系列业务行为，从而推导出系统所需的能力，并通过技术性的手段转化为系统的空间结构。而系统的空间结构就是系统的领域模型。
图3-7所示为一个对商城中同城配送需求进行事件风暴后得到的领域事件流。首先，事件风暴的展开是基于业务场景的。在这个需求中，领域专家识别出了店铺创建、同城配送设置、商品选购、订单确认、接单、配送几个业务场景。然后，展开每个业务场景，从左到右识别出该场景下的领域事件，以及触发该事件的命令和角色。这些事件流是后续建模工作的战术层输入，基于它们就可以逐步推演出领域模型。
经过事件风暴，既可发现与通用模型的重叠之处，也可找出差异点。如此，我们不仅最大程度复用了中台现有能力，也通过增加差异点持续扩展了中台的能力。
对于如何基于事件风暴构建业务中台领域模型，可参考图3-8所示流程。
1）业务架构师与领域专家主导，带领团队按照业务场景识别领域事件、命令与角色，并按照时间排序。
2）业务架构师与领域专家带领团队，基于战术层的业务场景与事件流提炼子域。对于中台来说，可以认为子域是能力中心。但这个时候，能力中心还处于问题域空间，没有任何解决方案。
3）技术人员带领团队基于事件流提取业务元素，识别实体、值对象及聚合。
4）技术人员再次带领团队，跨越到战略层，识别出限界上下文及其映射与集成的关系，并验证是否有足够的能力解决能力中心的问题。这个时候，能力中心的问题由限界上下文解决，业务中台架构终于从问题过渡到了解决方案。
3.3.2 需求结构化
业务中台的核心价值在于能力的共享。中台能力使用方在接触业务中台时面临的首要问题是：
如何了解业务中台有哪些能力？
这些能力与实际业务场景的匹配程度如何？
因此，业务中台的构建首先需要考虑业务能力的呈现方式。我们以业务场景、业务能力、业务配置的层次来结构化地表达业务需求。需求结构化体现的是一种结构化思维，即在面对需求问题时，采用一种层次结构将需求进行拆解。
在未中台能力结构化展现时，想要了解中台所提供的能力，一般是通过API列表，而且只局限于开发人员，因为业务人员不易理解API列表。但是，需求结构化不仅让我们更易于了解业务中台的共享能力，还扩大了受众人群。
需求结构化，一般可以从两个维度来体现。
能力地图：从领域、场景、能力的结构化层次，可视化地体现需求场景和流程中的每个节点。如此一来，中台能力使用方可基于原始需求快速匹配可用的业务领域、场景及能力。而对于不存在的业务场景，能力使用方则形成当前需求的场景能力开发项。
配置视图：在同一业务领域，不同的业务场景会导致不同的业务规则。通过配置视图，中台能力使用方可以查看业务中台已有的业务规则，与当前的业务场景规则进行匹配。若规则已存在但与当前所需的规则策略不匹配，则形成规则的扩展实现开发项；如规则为当前业务场景特有，则可以形成定制实现开发项。
综上，通过能力地图、配置视图，我们能够将业务场景、业务规则以系统结构层次的方式串联起来。按照需求结构化方式，针对具体需求，我们首先会整理出需使用的场景、能力、配置，并在现有的系统上梳理出需要新增的开发场景、能力、规则，形成最终需求需要开发和配置的条目。
业务中台不是一蹴而就的。需求结构化的方式一方面可以让中台使用方更易于应用共享能力，验证业务能力；另一方面也能不断沉淀更多的业务能力、业务规则配置及扩展项。这也是业务中台不断自我演进的方式。
