DDD实战课（3）：实战篇上

实战篇：几个实战项目

11 | DDD实践：如何用DDD重构中台业务模型？（略）

Part 1：传统业务转型互联网实例
实例背景（略）

构建中台业务模型

2种建模策略：自顶向下的策略、自底向上的策略

自顶向下的策略

先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。

自底向上的策略

第二种策略是自底向上。这种策略是基于业务和系统现状完成领域建模。首先完成需重构业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。

实例：保险业务转型。参见原文
第一步：锁定系统所在业务域，构建领域模型。
第二步：对齐业务域，构建中台业务模型。构建多业务域的中台业务模型的过程，就是找出同一业务域内所有同类业务的领域模型，对比分析域内领域模型和聚合的差异和共同点，打破原有的模型，完成新的中台业务模型重组或归并的过程。
第三步：中台归类，根据领域模型设计微服务。

重点是：重构过程中的领域对象，理解业务域、领域模型、聚合以及领域对象之间的关系。

业务域、领域模型表格图示

12 | 领域建模：事件风暴构建领域模型完整流程（略）

一般来说一个中型规模的项目，领域建模的时间大概在两周左右。

事件风暴概念

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

事件风暴准备

参与者：采用工作坊的方式，将项目团队和领域专家聚集在一起。
关注点：需要重点关注这类业务的语言和行为。比如某些业务动作或行为（事件）是否会触发下一个业务动作，这个动作（事件）的输入和输出是什么？是谁（实体）发出的什么动作（命令），触发了这个动作（事件）…我们可以从这些暗藏的词汇中，分析出领域模型中的事件、命令和实体等领域对象。

事件风暴构建领域模型

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

一、产品愿景

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

场景分析时会产生很多的命令和领域事件。我用蓝色来表示命令，用橙色表示领域事件，用黄色表示补充信息，比如用户信息数据来源于 HR 系统的说明。

实际上以目前的权限模块来看，不用DDD造成的问题就是后续一个新的方法的补充完全无规律，整个业务流散乱。

三、领域建模（重点）
根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。

三步：
第一步：从命令和事件中提取产生这些行为的实体。用绿色贴纸表示实体。