@mangojiji
他提到的做法就是 controller 入参出参用 VO ，数据库表对应对象用 PO ，中间的 service 或者其它 Job 、Util 、甚至连查表的返回对象和数据库查询参数之类的传输对象都用 DTO 。

因为这些概念是重叠覆盖的。

比如 POJO ， 什么 POJO ，只有属性没有方法的类都算，你提到的所有 O 都属于 POJO 细分后的一种。

什么是 DTO ，传输对象。 只要你用来当参数或者结果集的对象都算 DTO ， 所以 VO,PO,DO,BO 那些乱七八糟的 O 也都是可以算 DTO ，只是阿里发布的许多文档之类的，DTO 单独用来指那些不好归类到 VO ，PO 之类 O 的其它传输对象了。

如果你分层没像阿里或者其它复杂项目架构一样切的非常细，那么你所有不知道该叫什么的都叫 DTO 就行，或者 POJO 不带后缀都可以。


--------------

再接下来说说我的理解

VO： 不论是叫它值对象(Value Object)，还是展示层对象(View Object) 都是一个意思， 指的是展示层专用的、用来包装外部输入、输出的对象。
举个例子，(假设在没有前后端分离的项目中，后端需要校验表单输入)比如用户注册接口参数对象，包含字段 登录名、密码，确认密码、验证码； 确认密码字段对于后续处理没有意义，只在 view 用于校验，所以它可以是一个单独的 VO 对象，重复密码正确后，将这个 VO 中有用的部分复制给 service 层专用的入参对象。

BO：业务对象(Business Object)， 感觉好像只在阿里系规范用的比较深度的项目见过 XxxxBO ，我在小厂混没实际见过。
继续以上一个例子说，注册的 VO 中有价值的部分重新组装的数据传输对象就是 BO ，RegisterBO ，这个 Bo 包含登录名、密码等等，像上一个里提到的验证码，有些人是把它算额外的另一个单独业务处理，在 Controller 中调用其它方法直接校验了，所以这里的 BO 就不包含这个对象，而有些人则是认为验证码也是业务流程的一部分，应该归到这个 BO 里，在这一层处理。

DO：持久化对象，基本就是与各类存储服务库表结构对应的对象，我常见的写法里也没见人加 DO 后缀的， 这个没什么好解释的。
上一个 RegisterBO 中 可能最后会组转成，User 对象、UserExtra 对象、WechatUser 对象、Oauth2User 、SmsLog 等对象分别存储到各自的表里面。


---------
最后：

DDD 那一套还有严格按照阿里发布的规范搞的某些项目可能会区分这么多 O ，划分这么多层， 甚至还有的入参都从 VO 、BO 、DTO 里拆出来，单独叫 Execute 、Query 、RequestParam ，Command 。

但没那么多概念的项目我们实际上不会分那么细，从 Controller 到 Service 不管多少层，除了持久化对象，入参出参都叫 DTO 的项目也有。

把不同层的数据对象拆开最大的好处就是方便项目拆分，独立部署，每个项目只需要依赖自己层的对象，当项目跨部门甚至跨公司的时候方便上游改动时控制影响范围，以及避免下游改动涉及到上游时还得跨部门让别人配合扯皮。
如果整个项目所有部分的所有权都在自己手上时，不分那么细改起来也不麻烦。

@Neillou 目前按钮已经是一块玻璃了，触感靠震动反馈。
我只是不喜欢扫脸而已，要是有屏下指纹配合线性马达那多爽啊。