---

前言

DDD（domain driven design）领域驱动设计‌

  。

---

一、背景

1. 应用架构演进

2. 设计方式演进

3. DDD核心原则（面向业务进行架构）

4. 整体实施路径

1. 以企业愿景和战略为输入，结合行业趋势、竞品分析、客群分析、现状梳理和资产盘点等，全方面理解IT全貌；
2. 进行收敛和分析，重组问题域，判断优先级，形成实施路径规划；
3. 对逐个模块进行业务要件设计和基于DDD的IT设计，并分模块分阶段实施；
4. 实施过程中，对识别出来的共通能力持续进行演进、下沉，形成共通能力。

二、DDD介绍

1. 设计方法

2. 分段协作设计

3. 设计落地步骤

1. 领域分组
   识别基于专业知识领域和组织结构的分组

2. 识别场景
   识别业务场景

3. 识别流程
   ->识别业务主流程
   ->识别交互级流程
   ->业务状态迁移

4. 分析事件
   ->事件风暴输出（角色、上下文、读指令/指令、事件、实体）
   ->做业务聚合
   ->识别聚合根

5. 架构推导
   ->架构雏形（聚合根）
   ->架构雏形（领域服务）
   ->架构雏形（应用级别）
   ->重叠度分析
   ->共通演化
   ->模型转数据库

6. 微服务落地
   ->工程落地
   ->微服务落地

4. 事件风暴

1. 事件风暴(图例)

2. 事件风暴(输出)

【执行者】发起了【命令】，产生了【事件】，导致【领域模型】的状态变化

1. 决策命令
   （或命令，指令；领域事件的触发动作，代表业务流程上的重要业务决策；忽略读，着眼写）
   执行者(用户、外系统、定时任务、本体)

2. 领域事件
   （业务上发生的事，对系统产生重要影响；对内：产生了数据/触发了流程/状态发生变化；对外：发送消息）

3. 领域模型
   （或领域名词；业务上下文中的领域概念；命令或事件中出现的名称/现实中的事物/可以在未来抽象出的业务概念）

4. 界限上下文
   （业务上下文边界，交流时不会产生歧义或二义性统；一语言的重要保证）

5. 集成协同
   （界限上下文依赖，上下文映射，前后序关系；避免出现双向依赖/循环依赖/过长依赖）

5. 领域建模

1. 领域建模

聚合（Aggregate）是一组生命周期以及业务规则强一致的实体和值对象的集合，表达统一的业务意义。
聚合负责封装业务逻辑，通过一致性边界和统一语言，内聚决策命令和领域事件，容纳并识别领域名词为下列不同的抽象模型。

实体（Entity）是在相同上下文中具有唯一标识的领域模型，可变化，通过标识判断同一性

值对象（Value Object）是一种特殊的领域模型，值对象是以内容判断，不可变，同一性

聚合根（Aggregate Root）是聚合中最核心的实体，其他的实体和值对象都从属于这个实体

2. 聚合根

3. 聚合根业务架构

4. 界限上下文及子域划分

6. 领域服务划分

7. 服务共通化

三、设计落地步骤

1. 领域分组

识别基于专业知识领域和组织结构的分组。

1. 参与人员

业务Owner
解答疑问；非实时参与设计过程

产品/BA
说明业务流程SOP；说明要件详细，各画面内容/处理业务

架构师
完成架构设计文档及各阶段成果物

核心开发
了解要件及设计成果物，指导开发

主持人/教练
主持DDD工作坊，DDD知识导入，过程指导

2. 识别场景

识别业务场景。

1. 业务场景划分

• 输入
  需求：SOP、业务需求
  业务：业务方掌握的领域知识和原始需求

• 工作
  识别业务场景->识别主流程->识别交互流程->识别事件（【角色】在【规则】前提下，执行了【指令】，触发了【事件】）

• 输出
  场景分解及实施路径

输出示例：

• 业务场景划分过程

3. 识别流程

->识别业务主流程
->识别交互级流程
->业务状态迁移

1. 识别流程

• 输入
  需求：SOP、业务需求
  业务：业务方掌握的领域知识和原始需求

• 工作
  以主流程为索引快速对业务全貌进行普及、沿着正向流程、分支流程、异常分支的顺序，依次基于原型进行讲解

• 输出
  参与人员对业务的认知理解

4. 分析事件

->事件风暴输出（角色、上下文、读指令/指令、事件、实体）
->做业务聚合
->识别聚合根

1. 识别事件与指令

• 输入
  需求：SOP、业务需求
  业务：业务方掌握的领域知识和原始需求、工作坊参与人员对业务的认知

• 工作
  识别各业务节点（【角色】在【规则】前提下，执行了【指令】，影响了【实体】，触发了【事件】）

• 输出
  场景事件指令流
  场景事件风暴列表

输出示例：

• 场景事件指令流

从事件流到指令流，分解每一次业务动作。
某个角色在特定的环境和条件下，发起了某个（人机交互的）指令，触发了某个事件，影响了某个对象。

2. 识别聚合

• 输入
  场景事件指令流、场景事件风暴列表
  （必要时）：其他场景的聚合设计、上下游领域的领域专家掌握的领域知识、遗留系统的代码逻辑

• 工作
  识别场景节点的上下文关系/实体的状态变化
  UML设计（绘制状态迁移图）

• 输出
  聚合状态迁移图
  聚合级架构图

输出示例：

• 聚合状态迁移图

业务闭环、无逻辑硬伤；可能跨多项业务需求；

• 聚合级架构图
  

聚合间依赖关系；聚合间事件驱动关系

3. 聚合设计：聚合业务模型

• 输入
  场景事件指令流、状态迁移图
  业务需求、上下游领域对该聚合的查询需求

• 工作
  识别实体间依赖关系及上下游依赖
  UML设计（绘制聚合的逻辑ER图）

• 输出
  聚合业务模型

输出示例：

• 聚合业务模型

聚合内实体间关系（各实体主要属性及状态字段）

• 聚合根

聚合中最核心的实体，其他的实体和值对象都从属于这个实体

• 聚合建模

聚合（Aggregate）是一组生命周期以及业务规则强一致的实体和值对象的集合，表达统一的业务意义。
聚合负责封装业务逻辑，通过一致性边界和统一语言，内聚决策命令和领域事件，容纳并识别领域名词为下列不同的抽象模型。

实体（Entity）是在相同上下文中具有唯一标识的领域模型，可变化，通过标识判断同一性

值对象（Value Object）是一种特殊的领域模型，值对象是以内容判断，不可变，同一性

聚合根（Aggregate Root）是聚合中最核心的实体，其他的实体和值对象都从属于这个实体

4. 指令设计

• 输入
  该聚合的状态迁移图
  该聚合的聚合业务模型

• 工作
  识别该聚合的上下游依赖、指令执行时序
  UML设计（绘制时序图）

• 输出
  粗颗粒度的微服务分层时序图

输出示例：

• 分层时序图

聚合内实体间关系（各实体主要属性及状态字段）

5. 架构推导

->架构雏形（聚合根）
->架构雏形（领域服务）
->架构雏形（应用级别）
->重叠度分析
->共通演化
->模型转数据库

1. 应用架构设计

• 输入
  各场景的聚合设计产出物
  其他模块的聚合设计产出物

• 工作
  聚合相关度分析
  聚合重叠度分析（业务重叠、模型重叠、流程重叠、通用域与支撑域）

• 输出
  领域内子领域划分
  应用架构图
  下沉共通设计

输出示例：

• 领域内子领域划分

与聚合状态迁移图相印证；子领域内高内聚，子领域间松耦合

• 应用架构图

用户接口服务（BFF）；应用编排服务（AGG）；领域服务（Infra）

• 下沉共通设计

根据聚合重叠度分析，部分聚合下沉共通域

2. DB设计

• 输入
  聚合业务模型
  数据规范
  遗留系统DB定义

• 工作
  面向对象设计
  新旧DB集合差值分析

• 输出
  聚合物理模型
  新旧DB对比表
  数据导入规则说明

3. 接口设计

• 输入
  业务需求
  遗留系统的接口定义
  指令设计

• 工作
  根据指令设计，完成聚合接口定义

• 输出
  聚合接口定义

4. 事件设计

• 输入
  聚合状态迁移图
  聚合DB定义

• 工作
  根据聚合设计，完成聚合事件定义

• 输出
  聚合事件定义（含单事件体定义）

5. 接口逻辑设计

• 输入
  业务需求
  聚合DB定义、聚合接口定义、聚合事件定义

• 工作
  根据指令设计，完成聚合接口逻辑设计
  UML设计（绘制接口时序图）

• 输出
  细颗粒度的接口代码分层时序图
  其他IT逻辑设计说明

6. 事件消费逻辑设计

• 输入
  聚合状态迁移图
  聚合架构图

• 工作
  根据聚合设计，完成聚合事件消费逻辑设计
  UML设计（绘制事件消费时序图）

• 输出
  细颗粒度的事件消费代码分层时序图

7. 聚合批处理设计

• 输入
  业务需求
  系统设计

• 工作
  根据聚合设计，完成聚合批处理逻辑设计
  UML设计（绘制批处理时序图）

• 输出
  批处理逻辑设计说明材料
  细颗粒度的批处理代码分层时序图

---

本文的引用仅限自我学习如有侵权，请联系作者删除。
参考知识

---