术语和名词
- EventStroming(事件风暴)：事件风暴是一项团队活动，旨在通过领域事件识别出聚合根，进而划分微服务的限定上下文。在活动中，团队先通过头脑风暴的形式罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合，然后对于每一个事件，标注出导致该事件的命令（Command），再然后为每个事件标注出命令发起方的角色，命令可以是用户发起，也可以是第三方系统调用或者是定时器触发等。最后对事件进行分类整理出聚合根以及限界上下文。
- Entity（实体）每个实体是唯一的，且可以相当长的一段时间内持续变化。我们可以对实体进行多次修改，故一个实体对象可能和他先前的状态大不相同。但是由于他们拥有相同的身份标识，他们依然可以是同一个实体，例如一件商品在电商商品上下文中是一个实体，通过商品中台唯一的商品id来标示这个实体。
- ValueObject（值对象）:值对象用于度量和描述事物，当你只关心某个对象的值属性的时候，该对象可以作为一个值对象。实体与值对象的区别在于唯一的身份标识和可变性。当一个对象用于描述一个事物，但是又没有唯一标示，那么它就是一个值对象。例如商品中的商品类别，类别就没有一个唯一标识，通过图书、服装等这些值就能明确表示这个商品类别。
- Aggregate(聚合) ：聚合是实体的升级，是由一组与生俱来就密切相关的实体和值对象组合而成的，整个组合的最上层实体就是聚合。
- BoundedContext（界定上下文） 用来封装通用语言和领域对象，为领域提供上下文语境，保证在领域之内的一些术语。业务相关对象等（通用语言）有一个确切的含义，没有二义性。使团队所有成员都能够明确知道什么必须保持一直，什么必须独立开发。
DDD分层架构
- 展现层
展现层负责向用户显示信息和解释用户指令
- 应用层
应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象完成业务逻辑，应用层也是与其他系统的应用层进行交互的必要渠道，应用层服务尽量简单，他不包含业务规则或知识，只为下一层的领域对象协调任务，使他们互相协作，应用层还可以进行安全认证，权限校验，分布式或持久化事务控制或向外部应用发送基于事件的消息等。
- 领域层
领域层是软件的核心所在，实现全部业务逻辑并且通过各种校验手段保证业务正确性，它包含业务所涉及的领域对象（实体，值对象），领域服务以及他们之间的关系。他负责表达业务概念，业务状态以及业务规则，具体表现形式就是领域模型。
- 基础层
基础层为各层提供通用的技术能力，包括：为应用层传递消息，提供API管理，为领域层呢个提供数据库持久化机制，还能通过技术框架支持各层之间的交互。
服务视图
（一）微服务内的服务视图
微服务内有Facade接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。
- 接口服务
接口服务位于用户接口层，用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给应用层。
- 应用服务
应用服务位于应用层，用来表述应用和用户行为，负责服务的组合，编排和转发，负责处理业务用例的执行顺序以及结果的拼装。应用层的服务包括应用服务和领域事件相关的服务。应用服务可以对微服务内的领域服务以及微服务组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。
- 领域服务
领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。领域服务对同一个实体的一个或多个方法进行组合和封装。或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑，实体自身的行为在实体类内部实现。向上封装成领域服务暴露。为隐藏领域层的业务逻辑实现，所有领域方法和服务等均需通过领域服务对外暴露。为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。
- 基础服务
基础服务位于基础层。为各层提供资源服务（如数据库，缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。基础服务主要为repository服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用repository服务接口，利用repository实现持久化数据对象或直接访问基础资源。
（二）微服务外的服务视图
- 前端应用与微服务
微服务中的应用服务通过用户接口层组装和数据转换后，发布在API网关，为前端应用提供数据展示服务。
- 微服务与外部应用
跨微服务数据处理时，对实时性要求高的场景，可选择直接调用应用服务的方式（新增和修改类型操作需关注事务一致性）对实时性要求不高的场景，可选择异步化的领域事件驱动机制（最终数据一致性）
数据视图
DDD分层架构中的数据对象转化过程
应用服务通过数据传输对象完成外部数据的交换。领域层通过领域对象（DO）作为领域实体和值对象的数据和行为载体。基础层利用持久化对象（PO）完成数据库的交换。DTO与VO通过Restful协议实现JSON格式和对象转换。
前端应用与应用层之间DTO与DO的转换发生在用户接口层。如微服务内应用服务需调用外部微服务的应用服务，则DTO的组装和DTO与DO的转换发生在应用层。
领域层DO与PO的转换发生在基础层。
领域事件和事件总线
领域事件是领域模型中非常重要的部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，有助于形成完整的业务闭环。领域事件主要用于解耦微服务，各个微服务之间不再是强一致性，而是基于事件的最终一致性。
（一）微服务内的领域事件
微服务内的领域事件可以通过事件总线或利用应用服务实现不同聚合之间的业务协同。当微服务内发生领域事件时，由于大部分事件的集成发生在同一个线程内，不一定需要引入消息中间件。但一个事件如果同时更新多个聚合数据，按照DDD“一个事务只更新一个聚合根”的原则，可以考虑引入消息中间件，通过异步化的方式，对微服务内不同的聚合根采用不同的事务。
（二）微服务之间的领域事件
微服务之间的数据交互方式通常有两种：应用服务调用和领域事件驱动机制。
领域事件驱动机制更多的用于不同微服务之间的集成，实现微服务之间的解耦。事件库（表）可以用于微服务之间的数据对账，在应用、网络等出现问题后，可以实现源和目的端的数据比对，在数据暂时不一致的情况下仍可根据这些数据完成后续业务处理流程，保证微服务之间数据的最终一致性。
应用服务调用方式通常应用于实时性要求高的业务场景，但一旦涉及到跨微服务的数据修改，将会增加分布式事务控制成本，影响系统性能，微服务之间的耦合度也会变高。
（三）事件总线
事件总线位于基础层，为应用层和领域层服务提供事件消息接收和分发等服务。其大致流程如下：
-
服务触发并发布事件。
-
事件总线事件分发。
-
如果是微服务内的订阅者（微服务内的其它聚合），则直接分发到指定订阅者。
-
如果是微服务外的订阅者，则事件消息先保存到事件库（表）并异步发送到消息中间件。
-
如果同时存在微服务内和外订阅者，则分发到内部订阅者，并将事件消息保存到事件库（表）并异步发送到消息中间件。
为了保证事务的一致性，事件表可以共享业务数据库。也可以采用多个微服务共享事件库的方式。当业务操作和事件发布操作跨数据库时，须保证业务操作和事件发布操作数据的强一致性。
（四）事件数据持久化
事件数据的持久化存储可以有两种方案，在项目实施过程中根据具体场景选择最佳方案。
1、事件数据保存到微服务所在业务数据库的事件表中，利用本地事务保证业务操作和事件发布操作的强一致性。
2、事件数据保存到多个微服务共享的事件库中。需要注意的一点是：这时业务操作和事件发布操作会跨数据库操作，须保证事务的强一致性（如分布式事务机制）。
事件数据的持久化可以保证数据的完整性，基于这些数据可以完成跨微服务数据的对账操作。
微服务拆分路线
事件风暴
本阶段主要完成领域模型设计。
基于DDD的微服务设计通常采用事件风暴方法。通过事件风暴完成领域模型设计，划分出微服务逻辑边界和物理边界，定义领域模型中的领域对象，指导微服务设计和开发。
事件风暴通常包括产品愿景、场景分析、领域建模和领域对象和服务矩阵等过程。本文不对事件风暴详细方法做深入描述，如感兴趣可查阅相关资料。
1、产品愿景
产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
建议参与角色：业务需求方、产品经理和开发组长。
2、场景分析
场景分析是从用户视角出发，探索业务领域中的典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系，用以支撑领域建模。
建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。
3、领域建模
领域建模是通过对业务和问题域进行分析，建立领域模型，向上通过限界上下文指导微服务边界设计，向下通过聚合指导实体的对象设计。
建议参与角色：领域专家、产品经理、需求分析人员、架构师、开发组长和测试组长。
4、微服务拆分和设计
结合业务限界上下文与技术因素，对服务的粒度、分层、边界划分、依赖关系和集成关系进行梳理，完成微服务拆分和设计。
微服务设计应综合考虑业务职责单一、敏态与稳态业务分离、非功能性需求（如弹性伸缩要求、安全性等要求）、团队组织和沟通效率、软件包大小以及技术异构等因素。
建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。
领域对象及服务矩阵和代码模型设计
本阶段完成领域对象及服务矩阵文档以及微服务代码模型设计。
1、领域对象及服务矩阵
在微服务拆分完成后，根据事件风暴过程领域对象和关系，对微服务内聚合、实体、值对象、仓储、事件、应用服务、领域服务等领域对象以及各对象之间的依赖关系进行梳理，确定各对象在分层架构中的位置和依赖关系，建立领域对象分层架构视图，为每个领域对象建立与代码模型对象的一一映射。
建议参与角色：架构师和开发组长。
2、微服务代码模型
根据领域对象在DDD分层架构中所在的层、领域类型、与代码对象的映射关系，定义领域对象在微服务代码模型中的包、类和方法名称等，设计微服务工程的代码层级和代码结构，明确各层间的调用关系。
建议参与角色：架构师和开发组长。
领域对象及服务矩阵
领域对象及服务矩阵主要用来记录事件风暴和微服务设计过程中产出的领域对象属性，如：各领域对象在DDD分层架构中的位置、属性、依赖关系以及与代码对象的映射关系等。通过建立领域对象与代码对象的映射关系，可指导软件开发人员准确无误的按照设计文档完成微服务开发。
以下为领域对象及服务矩阵样例（部分数据，仅供参考）
| 层 | 聚合 | 领域对象名称 | 领域类型 | 依赖的领域对象 |
|---|---|---|---|---|
| 应用层 | / | 创建工单 | 应用服务 | 工单创建领域服务 |
| / | 反馈工单 | 应用服务 | 工单反馈 | |
| / | 确认工单 | 事件发布 | 工单待确认 | |
| 领域层 | 工单 | 售后工单 | 聚合根 | |
| 创建工单 | 命令 | |||
| 受理人 | 值对象 | |||
| 更改受理人 | 命令 | |||
| 创建、更新故障 | 故障领域服务 | 创建故障 | ||
| 创建、更新卡片 | 卡片领域服务 | 创建卡片 | ||
| 创建、更新赔付 | 赔付领域服务 | 创建赔付 | ||
| 客服 | 客服 | 聚合跟 | ||
| 创建客服信息 | 命令 | |||
| 组织关系 | 值对象 | |||
| 创建组织关系 | 命令 | |||
| 创建人员信息 | 领域服务 | 创建客服对象 | ||
| 创建组织关系 | 领域服务 | 创建客服组 | ||
| 基础层 | 客服状态变更 | 状态变更服务 | 状态变更接口 | |
| 工单流转 | 流转接口 |
各栏说明如下：
层：定义领域对象位于DDD分层架构中的哪一层。如：接口层、应用层、领域层以及基础层等。
聚合：在事件风暴过程中将关联紧密的实体和值对象等组合形成聚合。本栏说明聚合名称。
领域对象名称：领域模型中领域对象的具体名称。如：“请假审批已通过”是类型为“事件”的领域对象；“请假单”是领域类型为“实体”的领域对象。
领域类型：在领域模型中根据DDD知识域定义的领域对象的类型，如：限界上下文、聚合、聚合根（实体）、实体、值对象、事件、命令、应用服务、领域服务和仓储服务等。
依赖对象名称：根据业务对象依赖或分层调用依赖关系建立的领域对象的依赖关系（如服务调用依赖、关联对象聚合等）。本栏说明领域对象需依赖的其他领域对象，如上层服务在组合和编排过程中对下层服务的调用依赖、实体之间或者实体与值对象在聚合内的依赖等。
包名：代码模型中的包名，本栏说明领域对象所在的软件包。
类名：代码模型中的类名，本栏说明领域对象的类名。
方法名：代码模型中的方法名，本栏说明领域对象实现或操作的方法名。
微服务代码结构模型
微服务代码模型最终结果来源于领域对象及服务矩阵。在代码模型设计时须建立领域对象和代码对象的一一映射，保证业务模型与代码模型的一致性，即使不熟悉业务的开发人员或者不熟悉代码的业务人员也可以很快定位到代码位置。
（一）微服务代码总目录
Interfaces（用户接口层）：本目录主要存放用户接口层代码。前端应用通过本层向应用服务获取展现所需的数据。本层主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给Application层。主要代码形态是数据组装以及Facade接口等。
Application（应用层）：本目录主要存放应用层代码。应用服务代码基于微服务内的领域服务或微服务外的应用服务完成服务编排和组合。为用户接口层提供各种应用数据展现支持。主要代码形态是应用服务和领域事件等。
Domain（领域层）：本目录主要存放领域层代码。本层代码主要实现核心领域逻辑，其主要代码形态是实体类方法和领域服务等。
Infrastructure（基础层）：本目录存放基础层代码，为其它各层提供通用技术能力、三方软件包、配置和基础资源服务等。
（二） 用户接口层代码模型
用户接口层代码模型目录包括：assembler、dto和facade。
Assembler：实现DTO与领域对象之间的相互转换和数据交换。理论上Assembler总是与DTO一同被使用。
Dto：数据传输的载体，内部不存在任何业务逻辑，通过DTO把内部的领域对象与外界隔离。
Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。
（三） 应用层代码模型
应用层代码模型目录包括：event和service。
Event（事件）：事件目录包括两个子目录：publish和subscribe。
publish目录主要存放微服务内领域事件发布相关代码。
subscribe目录主要存放微服务内聚合之间或外部微服务领域事件订阅处理相关代码。为了实现领域事件的统一管理，微服务内所有领域事件（包括应用层和领域层事件）的发布和订阅处理都统一放在应用层。
Service（应用服务）：这里的服务是应用服务。应用服务对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。
（四） 领域层代码模型
微服务领域层包括一个或多个聚合代码包。标准的聚合代码模型包括：entity、repository和service三个子目录。
Aggregate（聚合）：聚合代码包的根目录，实际项目中以实际业务属性的名称来命名。聚合定义了领域对象之间的关系和边界，实现领域模型的内聚。
Entity（实体）：存放实体（含聚合根、实体和值对象）相关代码。同一实体所有相关的代码（含对同一实体类多个对象操作的方法，如对多个对象的count等）都放在一个实体类中。
Service（领域服务）：存放对多个不同实体对象操作的领域服务代码。这部分代码以领域服务的形式存在，在设计时一个领域服务对应一个类。
Repository（仓储）：存放聚合对应的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定一个原则：一个聚合对应一个仓储。
特别说明：按照DDD分层原则，仓储实现本应属于基础层代码，但为了微服务代码拆分和重组的便利性，我们把聚合的仓储实现代码放到了领域层对应的聚合代码包内。如果需求或者设计发生变化导致聚合需要拆分或重新组合时，我们可以聚合代码包为单位，轻松实现微服务聚合的拆分和组合。
（五） 基础层代码模型
基础层代码模型包括：config和util两个子目录。
Config：主要存放配置相关代码。
Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，可为不同的资源类别建立不同的子目录。
（六） 微服务总目录结构
微服务总目录结构如下：
