加微信：642945106 发送“赠送”领取赠送精品课程

发数字“2”获取众筹列表
下载APP 

16 | 视图：如何实现服务和数据在微服务各层的协作？
2019-11-20 欧创新
DDD实战课 进入课程 

讲述：欧创新
时长 17:23 大小 11.95M

你好，我是欧创新。

在 DDD 分层架构和微服务代码模型里，我们根据领域对象的属性和依赖关系，将领域对象进行分层，定义了与之对应的代码对象和代码目录结构。分层架构确定了微服务的总体架 构，微服务内的主要对象有服务和实体等，它们一起协作完成业务逻辑。

那在运行过程中，这些服务和实体在微服务各层是如何协作的呢？今天我们就来解剖一下基于 DDD 分层架构的微服务，看看它的内部结构到底是什么样的。

服务的协作

服务的类型

我们先来回顾一下分层架构中的服务。按照分层架构设计出来的微服务，其内部有 Facade 服务、应用服务、领域服务和基础服务。各层服务的主要功能和职责如下。

Facade 服务：位于用户接口层，包括接口和实现两部分。用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将数据传递给应用层。或者在获取到应用层数据后，将
DO 组装成 DTO，将数据传输到前端应用。

应用服务：位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果拼装，对外提供粗粒度的服务。

领域服务：位于领域层。领域服务封装核心的业务逻辑，实现需要多个实体协作的核心领域逻辑。它对多个实体或方法的业务逻辑进行组合或编排，或者在严格分层架构中对实体方法进行封装，以领域服务的方式供应用层调用。

基础服务：位于基础层。提供基础资源服务（比如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务应用逻辑的影响。基础服务主要为仓储服务，通过依赖倒置提供基础资源服务。领域服务和应用服务都可以调用仓储服务接口，通过仓储服务实现数据持久化。

服务的调用

我们看一下下面这张图。微服务的服务调用包括三类主要场景：微服务内跨层服务调用，微服务之间服务调用和领域事件驱动。

微服务内跨层服务调用

微服务架构下往往采用前后端分离的设计模式，前端应用独立部署。前端应用调用发布在
API 网关上的 Facade 服务，Facade 定向到应用服务。应用服务作为服务组织和编排者， 它的服务调用有这样两种路径：

第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。
第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。

微服务之间的服务调用

微服务之间的应用服务可以直接访问，也可以通过 API 网关访问。由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。

领域事件驱动

领域事件驱动包括微服务内和微服务之间的事件（详见  [第 06 讲]）。微服务内通过事件总线（EventBus）完成聚合之间的异步处理。微服务之间通过消息中间件完成。异步化的 领域事件驱动机制是一种间接的服务访问方式。

当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。

当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。

服务的封装与组合

我们看一下下面这张图。微服务的服务是从领域层逐级向上封装、组合和暴露的。

基础层

基础层的服务形态主要是仓储服务。仓储服务包括接口和实现两部分。仓储接口服务供应用层或者领域层服务调用，仓储实现服务，完成领域对象的持久化或数据初始化。

领域层

领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则。主要的服务形态有实体方法和领域服务。

实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。实体是微服务的原子业务逻辑单元。在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力。不必过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。

DDD 提倡富领域模型，尽量将业务逻辑归属到实体对象上，实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。

对于严格分层架构，如果单个实体的方法需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务。

应用层

应用层用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。

通过应用服务对外暴露微服务的内部功能，这样就可以隐藏领域层核心业务逻辑的复杂性以及内部实现机制。应用层的主要服务形态有：应用服务、事件发布和订阅服务。

应用服务内用于组合和编排的服务，主要来源于领域服务，也可以是外部微服务的应用服 务。除了完成服务的组合和编排外，应用服务内还可以完成安全认证、权限校验、初步的数据校验和分布式事务控制等功能。

为了实现微服务内聚合之间的解耦，聚合之间的服务调用和数据交互应通过应用服务来完成。原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联。

用户接口层

用户接口层是前端应用和微服务之间服务访问和数据交换的桥梁。它处理前端发送的
Restful 请求和解析用户输入的配置文件等，将数据传递给应用层。或获取应用服务的数据后，进行数据组装，向前端提供数据服务。主要服务形态是 Facade 服务。

Facade 服务分为接口和实现两个部分。完成服务定向，DO 与 DTO 数据的转换和组装， 实现前端与应用层数据的转换和交换。

两种分层架构的服务依赖关系

现在我们回顾一下 DDD 分层架构，分层架构有一个重要的原则就是：每层只能与位于其下方的层发生耦合。

那根据耦合的紧密程度，分层架构可以分为两种：严格分层架构和松散分层架构。在严格分层架构中，任何层只能与位于其直接下方的层发生依赖。在松散分层架构中，任何层可以与其任意下方的层发生依赖。

下面我们来详细分析和比较一下这两种分层架构。

松散分层架构的服务依赖

我们看一下下面这张图，在松散分层架构中，领域层的实体方法和领域服务可以直接暴露给应用层和用户接口层。松散分层架构的服务依赖关系，无需逐级封装，可以快速暴露给上 层。

但它存在一些问题，第一个是容易暴露领域层核心业务的实现逻辑；第二个是当实体方法或领域服务发生服务变更时，由于服务同时被多层服务调用和组合，不容易找出哪些上层服务调用和组合了它，不方便通知到所有的服务调用方。

我们再来看一张图，在松散分层架构中，实体 A 的方法在应用层组合后，暴露给用户接口层 aFacade。abDomainService 领域服务直接越过应用层，暴露给用户接口层 abFacade 服务。松散分层架构中任意下层服务都可以暴露给上层服务。

严格分层架构的服务依赖

我们看一下下面这张图，在严格分层架构中，每一层服务只能向紧邻的上一层提供服务。虽然实体、实体方法和领域服务都在领域层，但实体和实体方法只能暴露给领域服务，领域服务只能暴露给应用服务。

在严格分层架构中，服务如果需要跨层调用，下层服务需要在上层封装后，才可以提供跨层服务。比如实体方法需要向应用服务提供服务，它需要封装成领域服务。

这是因为通过封装你可以避免将核心业务逻辑的实现暴露给外部，将实体和方法封装成领域服务，也可以避免在应用层沉淀过多的本该属于领域层的核心业务逻辑，避免应用层变得臃肿。还有就是当服务发生变更时，由于服务只被紧邻上层的服务调用和组合，你只需要逐级告知紧邻上层就可以了，服务可管理性比松散分层架构要好是一定的。

我们还是看图，A 实体方法需封装成领域服务 aDomainService 才能暴露给应用服务
aAppService。abDomainService 领域服务组合和封装 A 和 B 实体的方法后，暴露给应用服务 abAppService。

数据对象视图

在 DDD 中有很多的数据对象，这些对象分布在不同的层里。它们在不同的阶段有不同的形态。你可以再回顾一下  [第 04 讲]，这一讲有详细的讲解。

我们先来看一下微服务内有哪些类型的数据对象？它们是如何协作和转换的？

数据持久化对象 PO(Persistent Object)，与数据库结构一一映射，是数据持久化过程中的数据载体。
领域对象 DO（Domain Object），微服务运行时的实体，是核心业务的载体。
数据传输对象 DTO（Data Transfer Object），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。
视图对象 VO（View Object），用于封装展示层指定页面或组件的数据。

我们结合下面这张图，看看微服务各层数据对象的职责和转换过程。

基础层

基础层的主要对象是 PO 对象。我们需要先建立 DO 和 PO 的映射关系。当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。

大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO 数据转换时，需要进行数据重组。

领域层

领域层的主要对象是 DO 对象。DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。

应用层

应用层的主要对象是 DO 对象。如果需要调用其它微服务的应用服务，DO 会转换为DTO，完成跨微服务的数据组装和传输。用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。

用户接口层

用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。

前端应用

前端应用主要是 VO 对象。展现层使用 VO 进行界面展示，通过用户接口层与应用层采用
DTO 对象进行数据交互。

总结

今天我们分析了 DDD 分层架构下微服务的服务和数据的协作关系。为了实现聚合之间以及微服务各层之间的解耦，我们在每层定义了不同职责的服务和数据对象。在软件开发过程 中，我们需要严格遵守各层服务和数据的职责要求，各据其位，各司其职。这样才能保证核心领域模型的稳定，同时也可以灵活应对外部需求的快速变化。

思考题

你知道在微服务内为什么要设计不同的服务和不同的数据对象吗？它体现的是一种什么样的设计思想？

欢迎留言和我分享你的思考，你也可以把今天所学分享给身边的朋友，邀请他加入探讨，共同进步。

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。

上一篇 15 | 边界：微服务的各种边界在架构演进中的作用？
下一篇 17 | 从后端到前端：微服务后，前端如何设计？

精选留言 **(25)

 写留言
。**
2019-11-20
欧老师你好

用户接口层：入参是DTO，内部将DTO转化为DO后调用应用层，将应用层的结果转化为V O后返回给前台
应用层：入参是DO，返回值是DO…
展开

作 者 回 复 : 1 、 可 以 的 。2、是否要做数据转换？主要是考虑解耦，这样各层不必受其它层的数据限制，它类似齿轮，通过数据转换来做适配。如果从前端到后端数据对象都是一样的，用一个对象其实也是可以的。要结合自己的场景来分析。

2
 

墨名次
2019-11-20
在数据试图这里，如果有用户User，那么在后端代码中是不是会有： com.xxx.xxx.po.User
com.xxx.xxx.do.User com.xxx.xxx.dto.User
或者为了方便区分则可以：…
展开

作者回复: 是的，但是有的时候不一定是一对一的关系。

 1

。


2019-11-20
欧老师，微服务之后，前后端分离。前端和后端的登陆认证用什么来做呢？基于token的方式，“退出登录”是假的退出吧？是不是只在前端应用删除了保存的key，对于后端应用， 这个key还是生效的

作者回复: 我们前端用JWT实现单点登录。后端微服务的服务调用通过API鉴权来控制。

1  1

William.加


2019-11-20
老师，微服务之间分布式事务，是有修改就用，还是应该根据具体业务做取舍？

作者回复: 根据你的业务来取舍吧，如果数据不一致没关系，或者数据不重要，部分数据丢了也可以，就可以不用。
如果是核心业务数据或者涉及到钱的业务数据，分布式事务就必不可少了。

 1

密码123456


2019-11-20
设计不同的对象，能够保证。当基于下层业务变化时。只需要更改，对象的转化即可。不需要对业务逻辑进行变更。对吗？
展开

作者回复: 是的。除非带来业务逻辑变化了，才去做变更。

 1

FIGNT


2019-11-23
1.应用层可以直接调用领域聚合的方法吗，还是说要通过领域服务去调用？
2.实体的方法一定要聚合封装一下吗？能不能先取出实体再调用方法呢？
3.多个聚合之间访问只能在应用层调用通过聚合id访问？
4. 一个聚合一个仓储，聚合之间有相同的内容怎么处理？比如一个大聚合做主流程业务， 包含了大部分的实体，小聚合只是维护性的增删改，小聚合完成增删改之后，大聚合需… 展开

作者回复: 1，可以的，松散分层架构就是这样的。严格分层架构需要封装后给应用层。2，实体方法需要通过聚合根来调用。
3，是的。
4，你可以将小聚合实体设计为大聚合实体的值对象。



二两豆腐


2019-11-22
DDD 本身是查无关性的，只关注于写。针对查询的花可以采用QCRS的方式进行查询。老师的讲解中，查询也在仓储中实现，仓储中的查询返回的PO，然后会被转化为DO。在很多应用场景中，前端的查询中是多样化的，也许很多字段并没有在DO中。请问老师这种情况应该怎么处理
展开

作者回复: 你说的没错。复杂查询选择自己最熟悉和方便的技术即可。聚合根根据ID查询可以在仓储实现。



你的美


2019-11-22
没问明白，就是一个聚合对应一个仓储，问：聚合对应的仓储在领域层只是接口吗，实质的存储地还是在基础层是这样吗？
还有我们一个微服务也要对应一个仓储，同样的问题：微服务在领域层只是一个接口吗， 实质存储地也是在基础层？
展开

作者回复: 聚合的领域层通过仓储接口来调用基础层的仓储实现。将DO转为PO，然后基础层将P O持久化到数据库。
你所说的微服务是不是我前面讲的类似小单体微服务？它也是可以采用仓储的方式的。



川杰


2019-11-21
请教一个问题，领域服务和领域事件的关系；
我理解领域服务说白了就是包裹处理某个业务模块的方法的类，领域事件也是用来处理业务的（主要是针对业务流程的关键节点）；
以用户举例：领域服务可以包括，对于用户实体的，增删改查方法；领域事件可以用来维护（用户新增完成事件、用户积分增加事件等）；…
展开

作者回复: 在领域服务或者应用服务中完成业务逻辑处理后。构建领域事件实体，直接调用事件发布的服务就可以了。



美美


2019-11-21
请教一下，后续架构演进过程中，领域层理解是比较好拆分的，但是应用层的逻辑理解是不太好拆分的，因为涉及了多个聚合
展开

作者回复: 在应用层一个聚合的应用服务你可以放在一个类里面，拆分的时候直接跟领域层聚合代码一起拿走就可以了。
如果应用服务的服务组合跨了多个聚合，这个拆分就相对复杂一些。你需要将原来的微服务内的应用服务，从基于DO的数据调用，转换为基于DTO的跨微服务的调用。代码改动量应该也不算太大。



xj_zh


2019-11-21
欧老师，时间允许，麻烦讲一下充血模型。
展开

作者回复: 先说一下贫血模型吧，贫血模型是指使用的领域对象中只有自己的属性以及setter和get ter方法，业务逻辑都不包含在领域对象中而是放在业务逻辑层。
而充血模型则是将实体相关的业务逻辑都放在实体的方法中实现，实体包含了自身的属性和业务行为，它在领域模型中就是一个具有业务行为和逻辑的实体。充血模型的实体更能体现领域模型的对象行为。

1





杨杰
2019-11-21
在第15章的例子里面讲逻辑边界的时候，有一张图有leave和person两个代码目录，表示两个逻辑边界。对于这个一直有疑问：这个逻辑边界（如图里面的leave和person）和聚合根是一对一还是一对多的关系？如果是一对一的关系，那么领域服务本身和聚合根封装的方法是不是有点儿重复了？
展开

作者回复: 其实放哪里都没关系的。你可以在一个聚合里单独建一个领域服务类，里面实现所有的领域服务，也可以直接在聚合根里用方法实现，毕竟聚合根可以引用所有的实体，对实体进行生命周期管理。
我建议你单独建立一个领域服务类，里面实现所有的领域服务，聚合根类只实现自己相关的业务逻辑。这样就相对清晰了。

2





宝宝太喜欢极客时间了
2019-11-21
老师，对VO不是很理解，是不是前端请求的返回封装成VO?

作者回复: 是的，用于前端展示的数据。





北天魔狼
2019-11-21
回复 涤生：
代码目录，包名，类名，方法名，事件名，理论解释，我认为已经够清晰了，有啥不懂可以讨论，不知道为啥你那么激动？送你一句：心中有花，看人即花

 

Kian.Lee
2019-11-21
从学习的角度这类数据对象要分清楚和理解它存在的意义，但从实际项目要根据项目自身特性和团队自身情况灵活应用，否则可能会本末倒置，DDD 是为了应对软件复杂性，而不是增加软件复杂性，哪些是核心的、哪些对当前项目是可以合并的、哪些是没有必要的都是架构时要思考的，当前团队成员的专业水准也是要考虑的，这么多概念架构师能深刻理解，开发人员是否也能理解，如何降低开发人员心智负担，如何实现常规业务零代码或…
展开

作者回复: 是的，就是这样的。理解后灵活运用。

 

张迪
2019-11-20
你知道在微服务内为什么要设计不同的服务和不同的数据对象吗？它体现的是一种什么样的设计思想？
解耦层与层之间的关系，减少层之间的依赖。
展开
 

张迪
2019-11-20
DO 和 PO 不能设计成一个吗？
展开

作者回复: 为了解耦，尽量不要设计成一个。

 

张迪
2019-11-20
还是不明白聚合根和领域服务之前的区别，聚合根和领域服务都是 实现需要多个实体协作的核心领域逻辑
作者回复: 聚合根的有些多个实体方法就是领域服务。所有的领域服务在一起就是一个领域服务类。
其实这个没关系，不用太纠结。 保证实体自己业务逻辑在自己的方法里实现就可以。至于领域服务是聚合根的方法还是在领域服务类里面，影响不大，都可以的。





张迪
2019-11-20
传入数据的格式校验放在哪层做？例如手机号格式校验、姓名长度校验等

作者回复: 前端可以做简单格式校验，稍微复杂数据的校验在应用层。业务规则和逻辑校验在领域层。
你说的这两个前端就可以校验。

3





郭嵩阳
2019-11-20
1.应用层是否可以调用应用层，也就是同级委托调用，因为在写代码时候，其他同级类可能已经实现了部分业务 2.充血模型中调用数据存储一般代码怎样写，一般我们跟数据库操作是mybatis，mybatis 的mapper 声明后是单例的 这个代码结构没考虑清楚.例如
@Component…
展开

作者回复: 1、你说的这种情况，这部分应用服务的功能可能可以沉淀到领域层了。应用服务调应用服务肯定是可以调用的。 2、你这里业务逻辑和基础服务逻辑混在一起了，可以考虑用仓储服务来实现依赖倒置，将业务逻辑和数据库逻辑解耦。
这是一个例子，有Person聚合根，Person仓储接口和仓储实现。

/*
Person聚合根
*/
public class Person{ private String id; private String name; private int age;
private boolean gender；
}

/*
Person仓储接口
*/
public interface PersonRepositoryInterface { void save(Person person);
void delete(String id);
}

/*
Person仓储实现
*/
@Repository
public class PersonRepositoryImp implements PersonRepositoryInterface { private PersonMapper mapper;
public void save( Person person) { mapper.create(person);
}
public void delete((String id) { mapper.delete(id);
}
}





2