Interfaces（用户接口层）：它主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

Application（应用层）：它主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

Domain（领域层）：它主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

Infrastructure（基础层）：它主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。

三、各层目录结构

1、用户接口层

Interfaces 的代码目录结构有：assembler、dto 和 façade 三类。

Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。

Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。

Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。

2、应用层

Application 的代码目录结构有：event 和 service。

Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和 subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。

这里提示一下：虽然应用层和领域层都可以进行事件的发布和处理，但为了实现事件的统一管理，我建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。

Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。

3、领域层

Domain 是由一个或多个聚合包构成，共同实现领域模型的核心业务逻辑。聚合内的代码模型是标准和统一的，包括：entity、event、repository 和 service 四个子目录。

Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。

以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。

Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。

Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。

Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，我建议你将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。

Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。

特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，我是把聚合仓储实现的代码放到了聚合包内。这样，如果需求或者设计发生变化导致聚合需要拆分或重组时，我们就可以将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。

4、基础层

Infrastructure 的代码目录结构有：config 和 util 两个子目录。

Config：主要存放配置相关代码。

Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。

5、代码模型总目录结构

四、注意事项

第一点：聚合之间的代码边界一定要清晰。聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。

第二点：你一定要有代码分层的概念。写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。如果将核心领域逻辑代码放到应用层，你的基于 DDD 分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。

有了代码模型架构，接下来就是怎么去细化模型里面的构造了，接下来将会详细讲解如何让领域模型和代码模型保持一致。

五、领域对象的整理

当微服务拆分完成后，我们就要整理事件风暴过程中产生的各个领域对象，比如：聚合、实体、命令和领域事件等内容，将这些领域对象和业务行为记录到下面的表格中。

你可以看到，这张表格里包含了：领域模型、聚合、领域对象和领域类型四个维度。一个领域模型会包含多个聚合，一个聚合包含多个领域对象，每个领域对象都有自己的领域类型。领域类型主要标识领域对象的属性，比如：聚合根、实体、命令和领域事件等类型。

六、从领域模型到微服务的设计

从领域模型到微服务落地，我们还需要做进一步的设计和分析。事件风暴中提取的领域对象，还需要经过用户故事或领域故事分析，以及微服务设计，才能用于微服务系统开发。

这个过程会比事件风暴来的更深入和细致。主要关注内容如下：

分析微服务内有哪些服务？

服务所在的分层？

应用服务由哪些服务组合和编排完成？

领域服务包括哪些实体的业务逻辑？

采用充血模型的实体有哪些属性和方法？

有哪些值对象？

哪个实体是聚合根等？

最后梳理出所有的领域对象和它们之间的依赖关系，我们会给每个领域对象设计对应的代码对象，定义它们所在的软件包和代码目录。

这个设计过程建议参与的角色有：DDD 专家、架构师、设计人员和开发经理。

七、领域层的领域对象

事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。在完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。

1. 设计实体

大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的。但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。

我们分析个人客户时，还需要有地址、电话和银行账号等实体，它们被聚合根引用，不容易在领域建模时发现，我们需要在微服务设计过程中识别和设计出来。

在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。

实体类放在领域层的 Entity 目录结构下。

2. 找出聚合根

聚合根来源于领域模型，在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期。个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。

聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。

3. 设计值对象

根据需要将某些实体的某些属性或属性集设计为值对象。值对象类放在代码模型的 Entity 目录结构下。在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。

有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析。如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。如果这个对象是多条且需要基于它做查询统计，我建议将它设计为实体。

4. 设计领域事件

如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件。首先确定领域事件发生在微服务内还是微服务之间。然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制。判断是否需要引入事件总线或消息中间件。

在个人客户聚合中有客户已创建的领域事件，因此它有客户创建事件这个实体。

领域事件实体和处理类放在领域层的 Event 目录结构下。领域事件的发布和订阅类我建议放在应用层的 Event 目录结构下。

5. 设计领域服务

如果一个业务动作或行为跨多个实体，我们就需要设计领域服务。领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑。你可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。

按照严格分层架构层的依赖关系，如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调用。所以如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。

个人客户聚合根这个实体创建个人客户信息的方法，被封装为创建个人客户信息领域服务。然后再被封装为创建个人客户信息应用服务，向前端应用暴露。

领域服务类放在领域层的 Service 目录结构下。

6. 设计仓储

每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作。仓储包括仓储的接口和仓储实现，通过依赖倒置实现应用业务逻辑与数据库资源逻辑的解耦。

仓储代码放在领域层的 Repository 目录结构下。

八、应用层的领域对象

应用层的主要领域对象是应用服务和事件的发布以及订阅。

在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法。为了响应这个命令，我们需要分析和记录：

在应用层和领域层分别会发生哪些业务行为；

各层分别需要设计哪些服务或者方法；

这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。

在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。

如果需要实现服务的跨层调用，我们应该怎么办？我建议你采用服务逐层封装的方式。

我们看一下上面这张图，服务的封装和调用主要有以下几种方式。

1. 实体方法的封装

实体方法是最底层的原子业务逻辑。如果单一实体的方法需要被跨层调用，你可以将它封装成领域服务，这样封装的领域服务就可以被应用服务调用和编排了。如果它还需要被用户接口层调用，你还需要将这个领域服务封装成应用服务。经过逐层服务封装，实体方法就可以暴露给上面不同的层，实现跨层调用。

封装时服务前面的名字可以保持一致，你可以用 *DomainService 或 *AppService 后缀来区分领域服务或应用服务。

2. 领域服务的组合和封装

领域服务会对多个实体和实体方法进行组合和编排，供应用服务调用。如果它需要暴露给用户接口层，领域服务就需要封装成应用服务。

3. 应用服务的组合和编排

应用服务会对多个领域服务进行组合和编排，暴露给用户接口层，供前端应用调用。

在应用服务组合和编排时，你需要关注一个现象：多个应用服务可能会对多个同样的领域服务重复进行同样业务逻辑的组合和编排。当出现这种情况时，你就需要分析是不是领域服务可以整合了。你可以将这几个不断重复组合的领域服务，合并到一个领域服务中实现。这样既省去了应用服务的反复编排，也实现了服务的演进。这样领域模型将会越来越精炼，更能适应业务的要求。

应用服务类放在应用层 Service 目录结构下。领域事件的发布和订阅类放在应用层 Event 目录结构下。

九、领域对象与微服务代码对象的映射

在完成上面的分析和设计后，我们就可以建立像下图一样的，领域对象与微服务代码对象的映射关系了。

典型的领域模型

个人客户领域模型中的个人客户聚合，就是典型的领域模型，从聚合内可以提取出多个实体和值对象以及它的聚合根。

我们看一下下面这个图，我们对个人客户聚合做了进一步的分析。提取了个人客户表单这个聚合根，形成了客户类型值对象，以及电话、地址、银行账号等实体，为实体方法和服务做了封装和分层，建立了领域对象的关联和依赖关系，还有仓储等设计。关键是这个过程，我们建立了领域对象与微服务代码对象的映射关系。

下面我对表格的各栏做一个简要的说明。

层：定义领域对象位于分层架构中的哪一层，比如：接口层、应用层、领域层以及基础层等。

领域对象：领域模型中领域对象的具体名称。

领域类型：根据 DDD 知识体系定义的领域对象的类型，包括：限界上下文、聚合、聚合根、实体、值对象、领域事件、应用服务、领域服务和仓储服务等领域类型。

依赖的领域对象：根据业务对象依赖或分层调用的依赖关系，建立的领域对象的依赖关系，比如：服务调用依赖、关联对象聚合等。

包名：代码模型中的包名，对应领域对象所在的软件包。

类名：代码模型中的类名，对应领域对象的类名。

方法名：代码模型中的方法名，对应领域对象实现或操作的方法名。

最后我们得出的微服务代码结构如下：

非典型领域模型

有些业务场景可能并不能如你所愿，你可能无法设计出典型的领域模型。这类业务中有多个实体，实体之间相互独立，是松耦合的关系，这些实体主要参与分析或者计算，你找不出聚合根，但就业务本身来说它们是高内聚的。而它们所组合的业务与其它聚合是在一个限界上下文内，你也不大可能将它单独设计为一个微服务。

这种业务场景其实很常见。比如，在个人客户领域模型内有客户归并的聚合，它扫描所有客户，按照身份证号码、电话号码等是否重复的业务规则，判断是否是重复的客户，然后对重复的客户进行归并。这种业务场景你就找不到聚合根。

那对于这类非典型模型，我们怎么办？

我们还是可以借鉴聚合的思想，仍然用聚合来定义这部分功能，并采用与典型领域模型同样的分析方法，建立实体的属性和方法，对方法和服务进行封装和分层设计，设计仓储，建立领域对象之间的依赖关系。唯一可惜的就是我们依然找不到聚合根，不过也没关系，除了聚合根管理功能外，我们还可以用 DDD 的其它设计方法。

声明：文章内容是极客时间专栏学习的学习笔记，会做简化或调整，欢迎大家留言和评论。

DDD从入门到精通，系列文章传送地址，请点击本链接https://blog.csdn.net/wanghaiping1993/article/details/125433802

DDD 领域驱动设计落地实践系列：微服务拆分之道

引言

在前面的两篇文章中，笔者给大家介绍了 DDD 核心思想、重要概念以及如何进行 DDD 进行微服务实践的大致过程，后续的文章中将逐渐深入 DDD 的实践细节，包括领域模型与代码模型的映射以及具体的微服务设计实例等。当下微服务盛行，微服务架构解决了单点系统的可用性问题、突破单节点服务的性能瓶颈同时提升了整个系统的稳定性。因此各大公司纷纷转向微服务架构，但是在实际的微服务拆分过程中也会遇到不少的问题。而 DDD 中的领域模型构建以及边界上下文的划分天然的和微服务划分有着异曲同工之妙，因此结合 DD 领域驱动设计来进行微服务拆分是一种比较好的微服务拆分方案。那么今天就和大家聊聊怎么进行微服务拆分。

为什么要进行微服务拆分？

在进行微服务拆分之前，我们首先应该搞清楚为什么要进行微服务拆分？微服务拆分后会带来怎样的业务价值？在后期维护上面会不会比以前的维护成本更低？我想这些问题都是架构师在实现微服务拆分之前需要回答的问题。那么我们就来先看看单体应用在业务不断发展的过程中会遇到怎样的问题。

维护难

随着业务的不断发展，单体应用的功能越来越多，需求不断变化，修改不断进行，单个应用多团队维护就会出现各种团队协作问题，不知不觉中降低了产品的研发效能。而且由于各个业务模块杂糅在一起，一个需求过来后，到底改哪个团队来做，经常在开会的时候吵得脸红脖子粗，增加了时间以及沟通成本。

更新难

进行需求迭代的时候，也许只修改了某个模块的功能，但是每次发布都是一整个大的包进行发布，其中构建、发包的时间成本会随着应用的迭代逐渐增加，导致整个需求上线过程变更显得十分笨重，不利于进行团队规模的敏捷开发。

稳定难

由于单体应用故障隔离范围只是线程级别的，单体应用可能会由于某个模块的功能有问题而导致整个服务平台的不可用，因此平台稳定性方面显然不能满足经常变化的业务发展的需要。

鉴于上述问题，我们需要对大泥球似的单体大应用进行合理拆分，以便于适用业务的快速发展。微服务架构拆分之后，团队成员不用都围绕一个大泥球应用转了，根据拆分的不同的业务域，各自负责自己的业务域，维护起来相对来说更加方便。同事如果有需求迭代，没有功能修改的业务域可以不用发生变更，不需要进行重新部署，大大降低了修改变更导致的平台稳定性性问题。另外由于是微服务分布式架构，不再是单点应用，不再存在单点问题，性能方面也会有所提升。

微服务到底该怎么拆？

当我们想清楚为什么进行微服务拆分之后，团队 Boss 也同意进行微服务拆分了。于是我们准备撸起袖子加油干的时候，另外一个问题又挡在我们前面，微服务到底应该怎么拆呢？或者换句话说，我们应该按照怎样的标准来进行拆分呢？如果拆分的不好，逻辑混乱的微服务还不如逻辑清晰的单体应用。这时候天空飘来了三个大字—DDD。

DDD 的理论中提供了我们进行领域驱动设计的指导方针，对于我们进行微服务的拆分具备天然的指导意义。比如 DDD 指导我们首先要对当前系统平台的业务进行全面的分析，可以通过用例分析法、事件风暴法以及四色建模法来进行业务分析，使用统一的业务语言进行业务领域划分以及边界上下文的划定，当然在这个过程中还包含了领域模型的构建，在业务分析中找到对应的实体、值对象以及聚合根，从而形成聚合，将聚合划分到边界上下文中。后面我们就可以根据边界上下文来进行具体的微服务的划分了。

笔者在实践微服务拆分的过程中主要按照业务能力、通用能力两个维度来进行具体的拆分。接下来给大家详细说明下。

业务能力

所谓业务能力就是平台的具体实现的业务功能是什么，这就好比在电商业务中物流域我们按照业务可以划分为仓储、运输、配送、计费等业务领域。大的领域划分出来之后，我们可以用真实的业务流程来串联这些业务领域。当业务流程经过这些业务领域的时候，必定会触发一些领域事件，经历一些业务流程，那么在这个过程中我们就可以梳理出对应的实体、值对象以及聚合根，我们将具有紧密业务逻辑关系的实体以及值对象收敛在聚合根的周围，从而形成聚合。例如在仓储领域中就会涉及到入库、库内操作以及出库这三大流程，其中入库主要包括质检、收货以及上架。这其中涉及到的实体主要用入库单、货品、操作员等，其中入库单就是聚合根，通过它可以将货品、操作员等实体以及值对象聚合起来，形成入库聚合。

通用能力

这里的通用能力其实包含两个意思，对于微服务本身来说，通用能力就是将各个微服务都涉及到的通用能力进行抽象形成单独的微服务。但是对于整个业务平台来说，通用能力实际就是业务中台。

1、通用服务

所谓通用服务就是在各个微服务之间都会碰到的问题，比如说接口的鉴权、日志的监控和管理、服务状态的监控和管理以及服务幂等等分布式系统问题。因此，我们需要将这些微服务的通用服务进行统一的抽象，形成通用的基础服务，这样微服务本身只需要关注自身的业务，这些微服务通用的能力由单独的基础服务来进行实现就 OK 了。

2、业务中台

我们还是拿大家最熟悉的电商业务来举个栗子吧，电商的业务形态有很多种，就阿里巴巴来说，有淘宝、天猫、主打生鲜的盒马、天猫超市等等。不管上层的业务形态有怎样的变化，实际上他们都是有比较核心的业务域是通用的，比如用户、支付、仓储、物流等等。那么实际上这些通用的业务对于整个电商平台来说实际就是通用能力，因此我们需要将这些通用的公共的能力进行下沉，形成业务中台，实现企业级的通用业务能力复用。

微服务拆分原则

在进行微服务拆分的过程中，有几条笔者总结的原则大家可以参考下，在实操的时候如果没有原则来遵循，实际我们自己也没办法去评判微服务拆分的效果到底有没有达到我们的预期。

微服务拆分要把握度

如果在微服务拆分过程中发生过度拆分，就会导致微服务爆炸的情况。不可避免的增加软件系统的维护成本，同时由于拆分也会导致业务流程变长，原本一两个服务就完成的业务，拆分后需要在五六个甚至更多的微服务才能完成，增加了平台出现 Bug 的概率，不知不觉中降低了平台的稳定性。另外更多的微服务意味着需要更多的服务器资源，从而在无形中增加了业务成本。因此我们可以借助于 DDD 划分的边界上下文，防止微服务过度拆分情况的发生。