网传一张图
PO（Persistant Object）持久对象
PO比较好理解
简单说PO就是数据库中的记录，一个PO的数据结构对应着库中表的结构，表中的一条记录就是一个PO对象
通常PO里面除了get，set之外没有别的方法
对于PO来说，数量是相对固定的，一定不会超过数据库表的数量
等同于Entity，这俩概念是一致的
BO（Business Object）业务对象
BO就是PO的组合
简单的例子比如说PO是一条交易记录，BO是一个人全部的交易记录集合对象
复杂点儿的例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象
BO是一个业务对象，一类业务就会对应一个BO，数量上没有限制，而且BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法
为什么BO也画成横跨两层呢？原因是现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成
很多情况下为了追求查询的效率，框架跳过PO直接生成BO的情况非常普遍，PO只是用来增删改使用
BO和DTO的区别
这两个的区别主要是就是字段的删减
BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，只要自己需要的数据，然后对外提供
在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成
DO是什么
一个是阿里巴巴的开发手册中的定义：DO（ Data Object）这个等同于上面的PO
另一个是在DDD（Domain-Driven Design）领域驱动设计中，DO（Domain Object）这个等同于上面的BO
我们的规范
开发规范
Domain 分层领域模型规约
（1）、Basic：公共对象，所有 NO 级的公共类放到 basic 包下，如：BaseXxx
（2）、PO（Persistent Object）：持久化对象，xxxPO，xxx 即为数据表相关名
（3）、BO（Business Object）：业务对象，作用一：联表查询，多个 PO 组成 BO 的情况；作用二：Service层中间状态处理一律用 BO 来替代 Map（除非是动态的Map），如果 PO 可以复用拿来即用（奥母卡剃刀）
（4）、DTO（Data Transfer Object）：数据传输对象，Service 或 Client 出入对象；如果 Service 层返回分页实体类，分页实体类就是DTO，比如：Page, 那么这个整体就是一个DTO，包括类似 List，那么整个就可以看成是 DTO（BO 同理可得）
（5）、VO（View Object）：显示层对象，Controller 出入对象；Controller 层统一封装返回 ResultVO
Ps1：Common 模块：领域模型实体类（domain.basic/vo/dto/bo/po），如：ResultVO 位于 domain.vo
Ps2：工具类封装实体类时，禁止带XxxNO，取名尽量靠近工具类业务本身含义，如：JsonModel 形参
Ps3：只允许 Basic/VO 可以设定默认值
Ps4：Service private 方法出/入参封装不作限制，但禁止使用静态 Map
其他规约
- 禁止无共识的缩写
- 注释：类、接口、方法、代码、字段
- 数据库表名格式：t_项目/模块名_po名
- Client 模块命名格式：xxxClient（只含接口），每次迭代更新版本号
- 公共异常类封装，尽可能减少代码中出现没必要的 try...catch...（统一处理）
- 日志打印：INFO：无论如何都要打印（微服务出入必须打印），DEBUG：排查问题打印
- 私有方法、工具类等非 MVC 分层方法：形参个数不做限制，除非复用率很高需要封装
- Common 项目模块：领域模型实体类（domain）、工具类（util）、常量类等，每次迭代更新版本号
- 访问修饰符：Controller 不允许存在 private，统一挪到 Service 处理；类中修饰符顺序位置：public -> protected -> default -> private
- 代码必须符合 Alibaba & Sonarqube 规范
- MapStruct 查看详情
