VO (View Object)，用于表示一个与前端进行交互的视图对象，它的作用是把某个指定页面(或组件)的所有数据封装起来。实际上，这里的 VO 只包含前端需要展示的数据，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在 VO 中体现出来。

DTO(Data Transfer Object)，用于表示一个数据传输对象，DTO 通常用于展示层(Controller)和服务层(Service)之间的数据传输对象。DTO 与 VO 概念相似，并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。

DO(Data Object) ，持久化对象，它跟持久层(Dao)的数据结构形成一一对应的映射关系。如果持久层是关系型数据库，那么数据库表中的每个字段就对应PO的一个属性，常是entity实体类。

BO（Business Object）：业务对象，就是从现实世界中抽象出来的有形或无形的业务实体。

阿里Java开发手册分层领域模型：

项目中，看到别人直接把DTO，写上swagger注释，直接返回前端。那么思考一下，为什么不建议这么做，不直接把DTO返回给前端。

从开发过程讲，前后端首先会以vo和param作为返回、传参的协议的定义，再定义协议之前，都没有实际的业务逻辑的处理，也就不会存在dto。

从项目的整体考虑，如果把dto作为传给前端的对象，那么service层返回dto，service层的所有的方法不一定都是public方法，也有private方法，如果private方法也返回dto，那么也就是说有些dto不是提供给前端的，有些是给前端的，这样就会乱，没有了隔离性。

从字段的修改来说，service层的方法是可以共用的，一个service方法返回的dto，可能会被很多个controlller方法使用到，即使目前不会，将来也可能会，dto会有很多参数，比如包含了主表信息，子表信息，而传给前端的vo只有dto的一部分信息，而且不同请求给前端看到的数据不一样，所以dto是共用的，vo是个性化的，如果直接把dto提供给前端，将会导致耦合性非常大，一旦一个接口的需求变了，修改了dto，增加了一个字段，将会导致接口直接把这个新增的字段返回给了前端，导致（接口输出数据多余，和不安全性）。同理，如果由于某个需求，把dto展示给前端的接口说要删除某一个字段，那么因为这个dto被很多接口引用，一删除就会导致出问题。

所以，总整体性结构而言：vo是必须存在的，不能把dto直接返回给前端。高内聚，低耦合。

1. VO可以复用吗？

比如，一个接口需要VO，另一个接口需要VO加上别的一些数据，这种情况，是继承VO使用，还是再写一个VO？

答案：VO最好不要复用。VO目的就是解耦，应该是并列关系的，如果存在复用，那么就可能导致，一方修改影响另一方。一旦存在继承关系，继承来继承去，最后关系就会变得很乱，不好维护。

2. Controller层接收的参数是VO还是DTO？ 希望大家根据公司情况来定，我们公司前端交互是统一VO的。

Controller层接收的应该是VO，但是根据情况而定，尤其是前后分离，有特定的前端开发人员时，因为DTO往往会添加很多额外的数据信息，打个比方，用户新增，往往前端传递的是账户名、密码、创建人标识等等很少的信息，但是DTO作为一个中转数据，会添加例如更新人、用户状态等等其他的信息，如果前端传递的是DTO，如此多的额外信息会给前端造成很多问题。如果是小项目的话，前后端都是一个人在进行，那就无所谓了，后端需要哪些，不需要哪些心里有数，传递DTO就无所谓了。

一般的数据传递是，前端传递VO给接口(Controller)，接口将VO转为DTO传递给service，service将DTO分解为DO，调用领域服务进行调度，然后逆向转为VO或者其他的返回结果，传递给前台。