正确认识服务和数据在微服务各层的协作

一、正确认识服务的协作

1. 服务的类型

按照分层架构设计出来的微服务，其内部有 Facade 服务、应用服务、领域服务和基础服务。之前都有提到，这里可以回忆一下！

2. 服务的调用（三类主要场景）

微服务的服务调用包括三类主要场景：微服务内跨层服务调用，微服务之间服务调用和领域事件驱动。

• 微服务内跨层服务调用

前端应用调用发布在 API 网关上的 Facade 服务，Facade 定向到应用服务。应用服务作为服务组织和编排者，它的服务调用有这样两种路径：

• 第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。

• 第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。

• 微服务之间的服务调用

微服务之间的应用服务可以直接访问，也可以通过 API 网关访问。

由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。

• 领域事件驱动

领域事件驱动包括微服务内和微服务之间的事件。

• 微服务内通过事件总线（EventBus）完成聚合之间的异步处理。
• 微服务之间通过消息中间件完成。异步化的领域事件驱动机制是一种间接的服务访问方式。

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

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

3. 服务的封装与组合

微服务的服务是从领域层逐级向上封装、组合和暴露的。基本如下图体现：

二、正确认识服务数据的协作

在 DDD 中有很多的数据对象，这些对象分布在不同的层里。它们在不同的阶段有不同的形态：

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

微服务各层数据对象的职责和转换过程如下：

1.基础层数据协作

基础层的主要对象是 PO 对象。

我们需要先建立 DO 和 PO 的映射关系：

• 当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。
• 当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。

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

2.领域层数据协作

领域层的主要对象是 DO 对象。

DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。

通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。

3.应用层数据协作

应用层的主要对象是 DO 对象。

如果需要调用其它微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。

用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。

4.用户接口层数据协作

用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。

Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。

5.前端应用数据协作

前端应用主要是 VO 对象。

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