领域驱动设计思维导图模板_ProcessOn思维导图、流程图

设计过程

设计地图

从业务中提炼出统一语言 基于统一语言建立领域模型 基于领域模型进行程序设计和编码实现 通过重构发现隐式概念，运行设计模式改进设计和开发质量

设计步骤

战略设计阶段

问题域发掘

分解问题域

限界上下文

上下文映射

识别核心领域与子领域

确定领域边界及关系

架构设计

隔离关注点

分层架构

表达领域与技术基础设施边界

六边形架构

分离查询和命令场景

CQRS模式

战术设计阶段

解决对象

问题域内部的复杂性

解决方法：分治

要素

值对象（Value Object) 实体（Entity) 领域服务（Domain Service) 领域事件（Domain Event) 资源库 (Repository) 工厂（Factory) 聚合（Aggregate) 应用服务（Application Service)

要素分类

领域模型对象

实体

值对象

领域服务

领域事件

边界

聚合

可以封装为一或多个实体与值对象

至少包含一个实体

只有实体才能作为聚合根

生命周期管理

工厂

负责领域对象的创建

资源库

从资源存放位置增删该查领域对象

数据库

内存

其他Web资源

不应暴露访问领域对象的技术实现细节

演进过程

从分层到领域驱动架构

演进足迹

使命：复杂度解决

复杂度来源

需求变化

复杂度分类

技术复杂度

质量属性

安全

高性能

高并发

高可用等

业务复杂度

业务扩张

复杂度表现与对策

规模

表现

问题域过于庞大而复杂

对策

分治，控制规模

结构

表现

业务复杂度和技术复杂度混淆

对策

保持结构的清晰与一致

变化

表现

无法控制业务和技术复杂度

对策

拥抱变化

领域驱动设计对策实现

总旨：隔离业务复杂度和技术复杂度

切割

垂直切割

拆业务：将一个庞大的软件系统切分为松耦合的多个小系统

领域场景识别

要素

Who

用户角色

What

业务功能

Why

业务价值

Where

场景的边界

限界上下文

When

hoW

如何实现业务价值

分析方法

要争取领域专家知识输入的机会

用例提取

用例的关注点就是领域

用例表达的领域概念必须使用统一语言

用户故事

模板

As a 角色 I would like 活动 so that 业务价值

要素

角色

支持对产品功能的细分，经常引出其他角色需要及相关活动的环境

活动

表述相关角色所需的系统需求

价值

传达为什么要进行相关活动，进场可以引领团队寻找能够提供相同价值且更少工作量的替代活动

要求

可测试，可验收

优秀实践

使用DSL编写用户故事

来自于行为驱动开发

测试驱动开发

先进性任务单元分解

站在调用者角度去思考

来自意图导向编程

遵循模式

Given-When-Then

Given

被测试对象的创建，及它与其他对象的写作

When

被测接口的方法明明及传入参数

考虑行为方式

命令式

查询式

Then

分析被测接口的返回值

分析基础

统一语言

水平切割

隔离业务与技术：对小系统进行领域治理

工具

分层架构

示例

关注点分离

领域层（Domain Layer)

业务逻辑

基础设施层（Infrastructure Layer)

业务逻辑依赖的技术实现

应用层（Application Layer)

业务逻辑的外观（Facade), 暴露体现业务用例的服务接口

业务逻辑和技术实现的粘合剂，实现两者之间的协作

六边形架构

示例

本质还是分层架构

六边形内部

领域层

应用层

六边形外部

基础设施层

内涵

关注点

如果把表示层换成其他实现，而与原来的实现有重复内容，则这部分内容就应该防灾业务逻辑层

外部可替换

自动测试

依赖倒置

核心概念

限界上下文（Bounded Context）

定义

上下文是动态的业务流程被边界静态切分的产物

是业务上的分割出的一个自治单元

目的意义

保护和隔离上下文边界，避免业务目标的不单一而带来的混乱与概念的不一致

目的不在于如何划分，而在于如何控制边界

关键点

知识

不通的限界上下文需要的领域知识不同

同一限界上下具有业务相关性

角色

上下文中的对象到底扮演了什么角色

角色和角色在上下文中是如何协作的

边界

上下文按照不同的关注点进行分离

边界根据耦合关系强弱来确定

越是关系最弱的地方，越是要划定边界

特征

高内聚低耦合

最小完备

完备

自治单元履行的职责是完整的，无需针对自己的信息求助别的单元

最小

避免将不必要的职责添加到该自治单元

自我履行

自治单元自身决定要做什么

要履行的职责一定是在掌握知识范畴之内

稳定空间

减少外界变化对限界上下文内部的影响

符合开放封闭原则(OCP)

对修改是封闭的

对扩展是开放的

独立进化

减少限界上下文变化对外界的影响

识别

从业务边界识别限界上下文

根据角色、业务活动和业务价值确定用例

通过用例精确业务场景

利用领域场景分析的用例分析方法剖析场景

从业务活动中提取出统一语言（从统一语言表中选择)

通常格式为动宾格式

通过相关性提炼出初步(粗糙)的限界上下文

语义相关性

主要看业务活动的宾语是否相同

功能相关性

从功能角度分析业务活动是否彼此关联或依赖

为业务边界命名

也可作为限界上下文识别的一种检验手段

在适当的时候对限界上下文进行重构

不应看成一蹴而就的事情

从工作边界识别限界上下文

从工作量和团队规模角度去拆分限界上下文

从应用边界识别限界上下文

从技术复用角度去拆分限界上下文

上下文协作关系（映射）

上下文团队合作模式

共享内核

客户方-供应方开发

遵奉者

分离方式

合作方式

极容易出现双向依赖

要精确识别到到底依赖的是什么，可不可以转换为其他合作方式

如果出现双向依赖，则应考虑是否可以放在同一上下文中

映射集成模式

防腐层 (Anticorruption Layer)

对付遗留系统时的首选模式

下游限界上下文对抗上游变化的利器

开放主机服务 (Open Host Service)

用途

上游服务用来吸引更多下游调用者的诱饵

用于承诺开放的服务不会轻易做出变化

常用开放方法

RPC (Protocol Buffer)

WebService

RESTFul

发布-订阅事件

作用

能够将上下文之间的解耦做到更好

常用方法

开发运行再同一个JVM中的事件总线来负责事件的发布和订阅

采用Actor模式支持事件的发布和订阅

适用范围

通常用于异步非实时的业务场景

往往用于实践驱动架构或者CQRS架构模式中（Command Query Responsibility Segregation 命令查询职责分离）

通信边界

通信边界的不同直接影响架构

边界分类

进程内

单体架构

进程间

数据库共享架构

通过数据库连接

零共享架构

通过协议和数据格式连接

领域知识

统一语言

意义

提炼领域知识的产物

获取统一语言就是需求分析的过程，也是团队角色就系统目标、范围和具体功能达成一致的过程

在沟通需求时，团队中的每个人都应使用同一语言进行交流

体现

统一的领域术语: 对应属性

所有的领域术语必须输出一张领域术语表，给出明确的概念解释，这是领域沟通的基础

在维护领域术语表时，一定要给出对应的英文术语，否则可能影响代码实现

领域行为描述：对应方法

要求

从领域的角度而非实现角度描述领域行为

若设计领域术语，必须遵循术语表的规范

强调动词的精确性，符合业务动作在该领域的合理性

要突出与领域行为有关的领域概念

意义

领域行为是对业务过程的描述

体现了更加完成的业务需求及复杂的业务规则

定义

在特定上下文中有角色触发的动作，并由此产生的业务流程和操作结果

同时是一种契约

明确前置条件

明确执行主语和宾语

明确执行结果

代码结构

层级

application

对应应用层

限界上下文中所有的应用服务

目的是使调用者了解的知识越少越好，调变得约越简单越好

传统上的controller属于这一层

domain

对应领域层

完全业务逻辑

repositories

对应资源库，如果不复杂可以集成在domain中

是gateways中的一种

gateways

对应基础设施层

网关组件自身会参与到业务中，但只是对业务的支撑，提供了与业务逻辑无关的基础功能实现

interfaces

对应应用层

对gateways中除persistence之外的抽象，包括访问数据库之外其他外部资源的抽象接口，以及访问第三方服务或其他限界上下文服务的抽象接口

interfaces与gateways从逻辑上来说可以为一对一的关系

示例

图示