PO(Persistant Object) 持久对象

用于表示数据库中的一条记录映射成的 java 对象。PO 仅仅用于表示数据，没有任何数据操作。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

可以理解是一个PO就是数据库中的一条记录；可以理解某个事务依赖的原始数据；好处是可以将一条记录最为一个对象处理，可以方便转化为其他对象

POJO (Plain Old Java Object)

POJO是“Plain Ordinary Java Object”的缩写，意为“简单的Java对象”。
POJO通常指的是一个没有任何限制、继承或实现特定接口的普通Java对象。POJO对象通常是一种轻量级的Java对象，没有任何框架或者注解的依赖。
在Java开发中，POJO对象通常用于表示简单的数据模型或者数据传输对象。最基本的 Java Bean 只有属性加上属性的 get 和 set 方法。可以转化为 PO、DTO、VO；比如 POJO 在传输过程中就是 DTO。

BO(Business Object) 业务对象

封装对象、复杂对象，里面可能包含多个类
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。

用于表示一个业务对象。BO 包括了业务逻辑，常常封装了对 DAO、RPC 等的调用，可以进行 PO 与 VO/DTO 之间的转换。BO 通常位于业务层，要区别于直接对外提供服务的服务层：BO 提供了基本业务单元的基本业务操作，在设计上属于被服务层业务流程调用的对象，一个业务流程可能需要调用多个 BO 来完成。

比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。

VO(Value Object) 表现对象

前端界面展示；value object值对象；ViewObject表现层对象；主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值；对于Android而言即是activity或view中的数据元素。

用于表示一个与前端进行交互的 java 对象。有的朋友也许有疑问，这里可不可以使用 PO 传递数据？实际上，这里的 VO 只包含前端需要展示的数据即可，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在 VO 中体现出来。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

DTO(Data Transfer Object) 数据传输对象

前端调用时传输；也可理解成“上层”调用时传输;
比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO.

用于表示一个数据传输对象。DTO 通常用于不同服务或服务不同分层之间的数据传输。DTO 与 VO 概念相似，并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。通常遵守 Java Bean 的规范，拥有 getter/setter 方法

DAO (Data Access Object)

DAO是“Data Access Object”的缩写，意为“数据访问对象”。
DAO层是整个应用程序中与数据库交互的核心部分。DAO层负责将数据库中的数据转换成Java对象，并将Java对象的数据保存到数据库中。
DAO层的主要作用是隔离上层业务逻辑和下层数据访问细节。在Java开发中，通常使用Hibernate等ORM框架来实现DAO层。DAO层的主要任务是实现数据的增删改查等基本操作，同时提供一些高级查询功能。

bean(可以包含业务逻辑代码，并且不一定与数据表对应)

包含的都是 JavaBean。

JavaBean 是一种 Java 语言写成的可重用组件。为写成 JavaBean，类必须是具体和公共的，并且具有无参数的构造器。JavaBean 通过提供符合一致性设计模式的公共方法将内部域暴露成属性。JavaBean 主要指的是一种规范，即包含一组 set 和 get 方法的类。JavaBean 可以使应用程序更加面向对象，可以把数据封装起来，把应用的业务逻辑和显示逻辑分离开，降低了开发的复杂程度和维护成本。

和 Entity Bean 的区别是，JavaBean 可以包含业务逻辑代码，并且不一定与数据表对应。

entity(字段必须和数据库字段一样)

包含的都是实体 bean，即 Entity Bean。

entity 的意思就是实体的意思，所以也是最常用到的，entity 包中的类是必须和数据库中的表相对应的，比如说：数据库有个 user 表，字段有 bigint 类型的 id，varchar 类型的姓名，那么 entity 包中的 User 类也必须是含有这两个字段的，且类型必须一致。不能数据库存的是 bigint 类型，User 类里的对应属性是 String 类型。这样做的好处是实体类和数据库保持一致，当用到 hibernate 或 mybatie 框架来操作数据库的时候，操作这个实体类就行，写 sql 之前不需要再做数据类型的处理。

model(前端需要什么我们就给什么)

model 大家不陌生，都知道是模型的意思，当用 model 当包名的时候，一般里面存的是实体类的模型，一般是用来给前端用的。比如：前端页面需要显示一个 user 信息，user 包含姓名、性别、所在地区，这些信息存在数据库的时候，姓名直接存姓名，但是性别和所在地区一般会用数据字典的编号存到数据库，比如：1 代表男，2 代表女，数据库存的就是 1 或 2，如果用 entity 的话，把 1、2 返回给前端，前端可能并不知道这是什么玩意，就算前端知道 1 代表男，2 代表女，也需要额外写一个 js 进行判断和相关的数据转换处理。如果后来数据库变动了，1 代表女，2 代表男，前端的 js 又需要重新写，很显然这样不利于维护。所以就需要 model 来解决，后端从数据库取了数据转化为前端需要的数据后再传给前端，前端就不需要对数据进行额外的处理，直接显示就行了。还有一种情况，数据库里面的 user 表字段有很多个，但是前端页面只需要显示姓名，如果把 entity 全部传给前端，无疑传了很多没用的数据。这时候 model 就很好的解决了这个问题，前端需要什么数据，model 就包含什么数据就行了。

model 是 MVC 中的概念，其中的类大部分是 POJO 类，用来给 View 组件提供要展示的数据，例如，用户个人信息界面，就可以将个人有关的所有信息封装成一个 POJO 对象，再将这个对象返回给客户端，客户端就可以解析里面的数据进行展示了。

一个 POJO 类如果都是用来提供展示数据的，那么就叫 VO，如果是用来传递数据的，就叫 DTO。例如，可以在视图层中，将用户请求参数数据封装成一个 VO 对象，再封装成 DTO 对象，再调用业务层的方法，将 DTO 对象作为参数进行传递，业务层根据 DTO 的数据进行相关业务的处理，再将数据封装成 DO 对象，再调用 DAO 的相关方法，将 DO 对象作为参数传递。DAO 对象就可以根据 DO 的数据对数据库进行操作（增删改查）。

domain(代表一个对象模块)

domain 这个包国外很多项目经常用到，字面意思是域的意思。比如一个商城的项目，商城主要的模块就是用户，订单，商品三大模块，那么这三块数据就可以叫做三个域，domain 包里存放的就是这些数据，表面上这个包和 entity 和 model 包里存的数据没什么区别，其实差别还是挺大的，特别是一些大型的项目。比如一个招聘网站的项目，最重要的对象就是简历了，那么简历是怎么存到数据库的呢，不可能用一张表就能存的，因为简历包含基本信息和工作经验，项目经验，学习经验等。基本信息可以存在简历表，但是涉及到多条的就不行，因为没人知道有多少条工作经验，项目经验，所以必须要单独建工作经验表和项目经验表关联到简历基本信息表。但是前端页面是不关心这些的，前端需要的数据就是一个简历所有的信息，这时就可以用 domain 来处理，domain 里面的类就是一个简历对象，包含了简历基本信息以及工作经验，项目经验等。这样前端只需要获取一个对象就行了，不需要获取基本信息的同时，还要从基本信息里面获取简历编号，再拿着简历编号去获取相关的工作经验、项目经验等信息。

当然，model 也是可以达到 domain 的效果。这个完全是看个人喜好和项目的整体架构，因为创建不同的 package 的作用本来也就是想把项目分成不同的层，便于管理和维护。如果你乐意，你可以创建 entity 包，然后在里面存图片，创建 images 文件夹，里面存 js，只是你自己看得懂还不够，你还要保证你的团队不会打死你。所以开发的时候，建类建包的命名规范性还是很重要的。