前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、领域驱动设计统一过程

领域驱动设计的核心是模型驱动设计，而模型驱动设计的核心又是领域模型，领域模型必须在统一语言的指导下获得。领域模型又可进一步细分为核心子领域、通用子领域和支撑子域。

系统上下文、限界上下文、分层架构和聚合都属于领域驱动设计的边界控制手段，他们的区别在于对业务划分的粒度和维度不同。

领域驱动设计的核心诉求是让业务架构和应用架构形成绑定关系，同时降低与技术架构的耦合，使得在面对需求变化时，应用架构能够适应业务架构的调整，并隔离业务复杂度与技术复杂度，满足架构的演进性。

1、全局分析阶段

对现实世界中问题的分析

目标：通过可视化的手段完成对问题空间的探索与分析

任务：通过执行价值需求分析和业务需求分析活动，深入剖析问题空间

活动：价值需求分析、业务需求分析

产物：全局分析规格说明书

1）价值需求分析

利益相关者、系统愿景和系统范围共同组成了目标系统的价值需求，分属于 5W 模型中的 Who、Why 和 Where。

5W	说明
Who	首先需要识别出目标系统的利益相关者。然后通过统一利益相关者的业务目标，明确目标系统的界限和方向
Why	最终做到明确系统愿景
Where	识别系统范围

a、利益相关者

支持者，比如组织、部门、员工和上游第三方合作伙伴

受益者，比如用户、下游第三方

注：上游指的是提供价值方，下游指消费价值方。

2）业务需求分析

业务需求分析阶段可分三个层级对业务需求进行逐级的问题拆解，如下。完成问题拆解后，即可梳理出核心子领域、通用子领域和支撑子领域。

第一层：业务流程 when

第二层：业务场景

第三层：业务服务 what

a、业务流程

第一层级，在业务目标指导下梳理出提供业务价值的动态业务流程。属于 5W 模型中的 When。

业务流程的起点往往由一个角色想目标系统发起服务请求，而要完成整个流程，则需要多个角色共同参与协作。业务流程的特点是：

1）具有时间属性

2）多角色参与

3）输出业务价值

识别业务流程的两个关键点是：完整和边界。完整是指要具有端到端的完整协作过程，体现一个完整的业务价值；边界仍然是从业务价值层面确定业务的范畴。

b、业务场景

第二层级，按照时间对业务流程进行切分，划分出每个时间阶段的业务场景，每个业务场景时可以由多个角色参与的。

场景就是角色之间为了实现共同的业务目标进行互动的时空背景，通过角色在特定时间、空间内执行的活动来推动情景的发展，形成角色与目标系统之间的体验与互动

问题1：业务流程与业务场景的区别与联系

答案：一个动态的业务流程是由一到多个静态的业务场景构成的，业务流程是端到端的完整协作过程，业务场景则是在业务目标的指导下在时间维度对业务流程的纵向切分。

c、业务服务

第三个层级，每个角色在业务场景下的一次功能性交互形成业务服务。业务服务是全局分析阶段的基本业务单元。属于 5W 模型中的 What。

1）提供了目标系统的核心价值，满足了利益相关者的价值需求的业务服务，归入核心子领域

2）属于业务需求一部分，但是横向支撑了多个领域服务，不具有明显的个性特征的业务服务，则归入通用子领域

3）起支撑和辅助价值的业务服务，归入支撑子领域

2、构映射阶段

解决现实世界与软件解决方案的桥接问题，根据全局分析阶段获得产出物（价值需求和业务需求），分别从组织级，业务级，系统级3个层次完成对问题空间的求解。映射为架构层面的解决方案

1）组织级映射

目标是确定系统上下文。根据价值需求分析的结果，通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。

2）业务级映射

目标是确定限界上下文。根据业务需求分析的结果，对相关的业务服务进行归纳和分类，形成限界上下文。限界上下文内部采用菱形对称架构模式组织业务数据 &服务，限界上下文之间采用限界上下文映射模式解决它们之间的协作问题。

设计限界上下文的四要素：最小完备、自我履行、稳定空间、独立进化

3）限界上下文映射模式

领域模型需要通过限界上线文来限定业务的自治边界，限界上下文之间也需要通过各种方式进行协助，那么根据不同的协作方式，上下文映射关系可以划分为以下 8 中模式：

• 客户方/供应方
• 共享内核
• 遵奉者
• 分离方式
• 开放主机服务
• 发布语言
• 防腐层
• 大泥球

4）系统级映射

目标是建立分层架构。分层架构位于系统上下文内部，可考虑如下分层

3、领域建模阶段

对软件解决方案内部进行进一步的分析建模。目标是在限界上下文内部建立领域模型。

领域建模可分为领域分析建模、领域设计建模和领域实现建模。

1）领域分析建模

产出：业务服务规约和领域模型概念图

在统一语言的指导下，通过快速建模法对业务服务进行提炼和抽象，获得领域分析模型。快速建模法是对“名次动词法”的丰富和补充，建立了标准化的领域分析建模过程，它分为如下四个步骤：

名词	说明
名词建模	识别业务服务规约中的名词。名词代表了候选对象，可将其映射为领域模型对象。
动词建模	识别业务服务规约中的动词。动词代表了候选对象上的候选操作，可将其映射为领域行为，若领域行为产生了过程数据（比如单据或交易记录等），则将该过程数据识别为领域概念。
归纳抽象	针对有定语修饰的领域概念进行归纳和抽象。
确定关系	确定领域概念之间的关系。

2）领域设计建模

对完整业务服务展开设计工作，获得领域设计模型。

产出：以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。

方法：角色构造型、服务驱动设计

名词	说明
实体	一个典型的实体应该具备身份标识、属性和领域行为这 3 个基本要素，符合信息专家模式，避免贫血模型。
值对象	不需要被追踪且是不可变的，通常作为实体的属性。
聚合	聚合是介于限界上下文和类之间的一个封装层次，它是边界而不是对象，边界内保证对象的一致性和完整性，对外作为一个整体参与业务行为的协作。
领域服务	如果领域行为是无状态的，或者需要多个聚合的协作，又或者需要访问外部资源，则应该将它分配给领域服务。
领域事件	主要用于表达领域对象状态的迁移，也可以通过事件来实现聚合乃至限界上线文之间的状态通知。
模式	统一语言、模型驱动设计、实体、值对象等 DDD 基本设计元素
资源库	资源库是对数据访问的一种业务抽象，它分离了聚合的领域行为和持久化行为，保证了领域模型对象的业务纯粹性。
工厂	管理聚合的创建过程。

3）领域实现建模

基于 TDD 完成代码设计和单测编写，获得领域实现模型。

产出：实现业务功能的产品代码和验证业务功能的测试代码。