写在前面：
1、无论是DO、BO、还是VO.…等。说到底都是用于区分和标识代码、并无强业务含义。
2、不必过分纠结各种命名、适合自己的才是最好的。如UserDO和User都可以表述数据库用户实体。没有最优的选择、只有最适合的。
模型层级关系
)
- PO（Persistant Object），用于表示数据库中的一条记录映射成的java对象。（和DO类似）
-
DO（Data Object），用于表示一个数据对象，常与数据库表一一对应，通过DAO层向上层传输数据。
在DDD领域驱动模型中，DO也可以称为Domain Object即领域对象
在Java体系中do是关键字，不能作为包名、所以常用model、bean、entity等作为包名。 -
BO（Business Object），用于表示一个业务对象，通过Service层向上层传递数据，如以下场景：
数据库中有商品表和价格表
GoodsDo (id、name、介绍、产地、发售时间)
PriceDO(原价、vip价格、促销价.....)
在描述一个商品的时候，如果直接用商品表的一条记录来表示，在真实的场景我们很容易就能发现可能缺少了很多对应的属性，如商品为什么会没有价格信息。这个时候就能够自然的引出BO
GoodsBO (id、name、介绍、产地、发售时间...各种价格、尺码...)
可以理解为BO可以作为DO的聚合，一个BO的属性可能需要到多个DO中去获取 -
VO（View Object），用于表示一个与前端进行交互的java对象。它可以等价于BO、也可以是多个BO的聚合、或是BO属性的精简
如:商品、价格案例中:
若不需要预售日期字段则可以在vo中去除。若需要附带工厂信息，则可以聚合GoodsBO和FactoryBO 。简单的说就是前端页面需要什么就给什么 -
DTO（Data Transfer Object），用于表示一个数据传输对象。
应用比较广泛常用于web -> service , service ->dao层传参。在业务不复杂时，可作为BO使用
一般的DTO 都指入参对象 - POJO（Plain Ordinary Java Object），表示一个简单java对象。
