DO（Data Object）

        阿里巴巴专指数据库表一一对应的 POJO 类。

一般在 业务逻辑层（Service） 对 数据库（SQL） 的 访问时 接收数据 使用。

xxxDO，xxx即为数据表名

另外：DO与Entity概念上浅显的相同，他们在实际应用中是一个东西。稍微的不同点就是DO是与数据库存在着某种映射关系的Entity，总的来说DO是Entity的一种。

VO（View Object）视图模型
        用于和前端的交互，接受前端回传的数据，返回给前端，做视图展示

xxxVO，xxx一般为网页名称。

AO（Application Object）应用对象
        AO是一个较为笼统的概念，因为太过于常见而并没有刻意的去描绘它的细节。举一个很简单的栗子：控制层（Controller） 在 业务逻辑层（Service） 查询一条或多条数据，这个数据的传输过程的运载就是AO完成。在正常的业务逻辑中一般都有很多种类型的数据，例如 整形、字符型、集合、类 等，我们把它统称为AO。

在**控制层（Controller）**与 **业务逻辑层（Service）**层之间抽象的复用对象模型，有时候极为贴近展示层，复用度不高。

BO（ Business Object）业务对象
        业务对象(Business Object，BO)是对数据进行检索和处理的组件。主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。形象描述为一个对象的形为和动作，当然也有涉及到基它对象的一些形为和动作。

一般用在包含业务功能模块 的具体实例上，比如我们写了一个Controller、一个Service、一个DAO、一个工具类等等这一系列实例组合后能实现一些功能，这些一系列实例组合为一个组件，这个组件就是BO。

POJO（ Plain Ordinary Java Object）纯普通Java对象
        POJO 专指只有 setter/getter/toString 的DTO。总的来说POJO包含DO、DTO、BO、VO，这些本质上都是一个简单的java对象，实际就是普通JavaBeans，是为了避免和EJB混淆所创造的简称

PO（Persistent Object）持久化对象
    与数据库的属性和字段一一对应

Entity（应用程序域中的一个概念）实体
        Entity（应用程序域中的一个概念）实体

        Eitity是一个未被持久化的对象，它是一个类，从现实抽象到代码的一个类。

Model （概念实体模型）实体类和模型
        Model是计算机程序设计中有两个概念：一个是三层架构中的实体类，另一个是MVC架构中的模型。

3.与MVC三层架构的关系

        在“三层架构”中，为了面向对象编程，将各层传递的数据封装成实体类，便于数据传递和提高可读性。

        在MVC（模型Model-视图View-控制器Controller）模式中，Model代表模型，是业务流程/状态的处理以及业务规则的制定，接受视图请求的数据，并返回最终的处理结果。View代表视图，用来解析Model带来的数据模型。业务模型的设计可以说是MVC最主要的核心。

        通常意义上的三层架构就是将整个业务应用划分为：表现层、业务逻辑层、数据访问层。区分层次的目的即为了“高内聚，低耦合”的思想。

表现层（web）：用于接收用户提交请求及响应处理。
业务逻辑层（service）：对数据业务逻辑处理。
数据访问层（dao）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等

4.总结

PO持久对象：与数据库的属性和字段一一对应

DO领域对象：基于实体和事件的业务对象，在构建复杂的系统的时候，采用领域驱动的设计思想，可以降低开发的复杂度

DTO数据传输对象：用于不同应用的数据传输，分布式，微服务的名称

VO值对象：用于和前端的交互，接受前端回传的数据，返回给前端，做视图展示

BO业务对象：封装多个PO，在Service层处理各种业务

4.1.为什么要分这些对象

因为在不同的业务中，同一个对象的作用是不同的，比如添加用户需要密码，但是查看信息，就只能返回部分的信息，甚至敏感信息要特殊处理，虽然有注解可以帮助我们解决这些问题，但是，处理的并不全面，而且不能视情况处理，反而增加了业务的复杂度
减少业务直接的耦合，当我们的需求有变动的时候，我改变字段的内容，不会影响到其他的业务的正常执行
让程序员做到见名知意，我们在命名对象的时候，就要以XXXDO，xxxVO命名，这样其他程序员在维护我们代码的时候，也知道应该怎么处理这些信息

4.2.什么时候需要定义这么多O

项目中真的有必要定义VO，BO，PO，DO，DTO吗？按照理论上来讲

如果项目比较小，是一个简单的MVC项目，又是单兵作战，我不建议使用VO，BO，PO，DO，DTO，直接用POJO负责各个层来传输就好，因为这种项目的“目的地”是快速完成。
而我们更多的时候，是持续迭代的团队协作项目，这个时候我们就建议用VO，BO，PO，DO，DTO，而且团队内要达成共识，形成一个标准规范。

4.3.实体对象之间如何转换？

BeanUtils.copyProperties(srcVo,destDto);
mapper.map(srcVo,DestDto.class);

参考资料

参考深入理解 DAO的概念_旷野历程的博客

概念POJO晓风残月淡的博客

《阿里Java 开发手册黄山版》

vo、dto、bo、do、po的概念理解Albertliuc的博客