目录
阶段一：识别业务领域和子域及其类型
阶段二：定义业务界限上下文
阶段三：分析业务界限上下文之间的依赖关系
阶段四：基于子域进行领域建模分析，构建聚合并形成服务
阶段五： 设计微服务和微服务分层架构
今天给大家介绍一下基于DDD微服务架构构建旅程，希望大家能得到有价值的经验并应用到实际的项目中！
以下是基于DDD的微服务架构构建旅程，分为五个主要的阶段：
- 识别业务领域和子域及其类型
- 定义业务界限上下文
- 分析业务界限上下文之间的依赖关系
- 基于子域进行领域建模分析，构建聚合并形成服务
- 设计微服务和微服务分层架构
阶段一：识别业务领域和子域及其类型
这个阶段主要是识别实际项目的业务领域，子域及其类型。
领域可以拆分为多个子领域。一个领域相当于一个问题域，例如：标签管理领域，领域拆分为子域的过程就是大问题拆分为小问题的过程。例如：标签子域，人群子域，元数据管理子域等。子域还可根据需要进一步拆分为子子域，其实就是将问题不断分解的一个过程，直到一个领域的复杂问题被分解为足够小，足够别清晰的描述和分析时为止。
DDD中把领域或子领域分为三种类型，核心域，支撑域和通过域。
核心域是企业需要重点构建的能力，是企业的核心竞争力。
支撑域是带有企业特性的能力，可以通过外包开发。
通用域是没有企业特性的通过能力，可以通过外购的形式具备。
进行分类的目的也是为了进行企业能力构建排序，把企业的核心竞争能力先构建，让企业占领市场先机，使企业立于不败之地。
由于企业所属的行业不同，关注的业务不同，所以每个企业的核心域，支持域和通用域也是不一样的。
以下就是一个标签管理系统的例子，标签子域和人群子域就属于核心域，元数据管理子域就属于支持域。
阶段二：定义业务界限上下文
限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，可以在统一的领域边界内用统一的语言进行交流。
例如：商品是电商领域的领域对象，用户在下单成功后购买某商品，进入到物流领域，商品就变成发货的物品，虽然它们都指同一个事物。所以这就是为什么我们要定义业务界限上下文，确定一个清晰的语义环境，去除二义性。
限界上下文的定义就是：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
下面标签管理系统就根据实际的业务场景，就基于子域设定了业务界限上下文，例如，标签上下文，人群上下文，元数据管理上下文和其它子域上下文。有的项目根据实际情况，基于子子域设计了业务限界上下文。
业务限界上下文可用于定义系统内部的一个架构边界，决定系统架构的设计。
在DDD方法论中，有三个边界的定义
- 物理边界：指独立运行的服务进程，一个独立部署微服务的边界就是物理边界，物理边界一般就是业务限界上下文的边界。
- 逻辑边界：指微服务内包含聚合的边界，一个微服务可以包含一个或多个聚合，微服务的演进就是以聚合为基础，进行不断的合并和拆分。
- 代码边界: 指代码目录的边界， 以DDD经典的四层代码分成架构，六边形架构或圆葱架构为指导，来定义清楚的代码目录边界，用于代码级别的代码架构定义与维护。
阶段三：分析业务界限上下文之间的依赖关系
这个阶段主要用于分析业务限界上下文之间的依赖关系，如下图的表格中，有五种关系
- OHS：开放主机服务
- PL：发布语言
- ACL：防腐层
- PS：合作关系，一般这种关系用的是最多的，表示两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- SK：共享内
如下图所示：标签管理系统相关的业务界限上下文都使用PS关系，D表示依赖，U表示使用，例如：人群上下文依赖使用标签上下文，标签上下文依赖使用元数据管理上下文。
阶段四：基于子域进行领域建模分析，构建聚合并形成服务
事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，最后对事件进行分类，整理出实体、聚合、聚合根，限界上下文然后映射为对应的服务。
而事件风暴正是 DDD 战略设计中经常使用的一种方法，它可以快速分析和分解复杂的业务领域，完成领域建模。
- 在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。
- 通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。
- 微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应
下边这个例子就是标签管理上下文和它包含的聚合，标签上下文将做为微服务的物理边界，进行独立部署，聚合将做为微服务合并和拆分的逻辑边界。
- 标签管理聚合
- 自定义标签管理聚合
- 标签市场聚合
阶段五： 设计微服务和微服务分层架构
按照上下文去定义微服务，例如：标签管理系统根据上下文，有以下四个微服务被定义：
- 标签服务
- 人群服务
- 元数据管理服务
- 其它通用服务
然后每个微服务都按照以下DDD分层架构进行设计：
----------------------------------
大家好，我是流水，一个资深的IT从业人员和架构师. 非常高兴您能搜索到，并看到这篇文章，希望这篇文章的内容能给您带来新的知识和帮助。
也欢迎扫描以下的二维码或微信搜索 “superxtech”，关注我的微信公众号 , 我会把更多更好的IT领域技术知识带给您！
----------------------------------