数据对象视图

微服务的数据对象

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

• 视图对象VO（View Object）
  用于封装展示层指定页面或组件的数据。

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

基础层

• 入参是DO，内部将DO转化成PO进行数据库的增删改查
• 执行结果用PO去映射，再转化为DO作为基础层的返回值

先建立DO和PO的映射：

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

大多数情况下PO和DO一一对应。但也存在DO和PO多对多，在DO和PO数据转换时，需数据重组。

比如时间范围查询时，会有辅助字段，如：beginTime和endTime，PO这怎么处理？我们的处理方式是增删改用PO，查询时候用QueryPO，QueryPO继承了PO并额外增加用于查询的辅助字段（比如时间、集合、模糊查询等）。

有的查询功能，比如按照名称查询，查询条件就是name，DTO、DO和PO是一样的，也需要在每一层都去转化一下么？我们把查询时的对象命名为QueryPO，从用户接口层到基础层的入参都是这一个，这样可以么？

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

一般聚合根用的少，很多情况聚合根要作为对象传到基础层。

领域层

入参是DO，返回值是DO。

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

应用层

入参是DO，返回值是DO。

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

用户接口层先完成DTO到DO的转换，然后应用服务接收DO进行业务处理。

如果DTO与DO是一对多的关系，就需进行DO数据重组。

用户接口层

• 入参是DTO，内部将DTO转化为DO后调用应用层
• 将应用层的结果转化为VO后返回给前台

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

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

前端应用

主要是VO。

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

参考

• 视图：如何实现服务和数据在微服务各层的协作？