POJO JavaBean DO BO DTO VO PO SO
DTO
Data Transfer Object，用于展示层与服务层之间的数据传输对象。 用来封装和接收 HTTP 请求中的参数；
用来封装和接收其他程序请求调用传递过来的参数；
Request
叫法不同，但应该和 DTO 起到一样的作用，请求的入参都通过 XXXRequest 来封装、 大概应该和 DTO 二选一。
VO
https://www.baeldung.com/java-pojo-javabeans-dto-vo#vo
Value Object，也称为值对象，是一种特殊类型的对象，可以保存 java.lang.Integer 和 java.lang.Long 等值。
VO 应该总是覆盖 equals() 和 hashCode() 方法。VO 一般会封装数字、日期、字符串等小对象。它们遵循语义，即它们直接更改对象的值并传递副本而不是引用。
使值对象不可变是一种很好的做法。值的更改仅通过创建新对象发生，而不是通过更新旧对象本身的值发生。
这有助于理解两个创建相等的值对象应该保持相等的隐式约定。
示例定义 EmployeeVO 并且覆盖 equals() 和 hashCode() 方法：
public final class EmployeeVO {
private final String firstName;
private final String lastName;
private final LocalDate startDate;
public EmployeeVO(String firstName, String lastName, LocalDate startDate) {
this.firstName = firstName;
this.lastName = lastName;
this.startDate = startDate;
}
// Getters
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass()) return false;
EmployeeVO emp = (EmployeeVO) obj;
return Objects.equals(firstName, emp.firstName)
&& Objects.equals(lastName, emp.lastName)
&& Objects.equals(startDate, emp.startDate);
}
@Override
public int hashCode() {
return Objects.hash(firstName, lastName, startDate);
}
}
Response
叫法不同，但应该和 VO 起到一样的作用，返回结果都通过 XXXResponse 来封装
大概应该和 VO 二选一。
PO
Persistent Object，持久化对象，和持久层（如数据库）形成对应的映射关系
对应数据表的 Java 对象，属性列表应该和数据表中的字段完全一致。
DO
Domain Object，领域对象，从现实世界中抽象出来的有形或无形的业务实体。
Entity
实体对象由 Entity 承担
SO
Service Object，服务对象。
在典型的分层应用程序体系结构中，有3个不同的层：
- 表示/视图层
- 服务/业务层
- 数据访问/持久层
表示或视图层由负责传入请求接口的所有“Web”或“Rest”类组成；
顾名思义，数据访问或持久层只是一个用于封装数据相关逻辑的层，DAO 和 DTO 模式实际上都位于这一层；
最后，服务层是负责核心业务逻辑的层，因此这是服务对象所在的层。
服务对象（SO）只是一个用于封装业务逻辑的对象。
这个 SO 的一个常见示例是服务类。比如：ItemService
是为了处理包含多个 POJO 对象（即对多个表的数据操作）时，进行事务的管理。
Service 层（其接口的实现类）被注入一个或多个 DAO 对象，以完成有意义的数据操作。
一般，Service 中的一个方法为一个事务，里面调用多个 DAO 对象的方法完成一个业务逻辑上的操作。
BO
Business Object，业务对象。
它是一个包含业务逻辑代码的对象。
简而言之，BO 几乎就是一个 SO。
这只是 enterprise Java 世界中的术语问题。
但是，一些开发人员还在其他地方使用 BO。
你可能已经看到包含大量业务逻辑但实际上并没有被归类为 'Service Object'（服务对象）的类，因为它没有向调用 Web 层的 REST 控制器暴露‘Service’（服务）层约定。
这是 BO 与 SO 的不同之处。
当可以将业务逻辑代码放在 SO 中以有效地将 SO 转换为 BO 时，可以考虑将业务逻辑代码抽象到它自己的类—— BO 中。
让 SO 本身成为许多单独业务对象的“facade”（外观）或“orchestrator”（协调器）。
BO 和 SO 是 N:1的关系；
SO 中的一个方法可能需要调用多个 BO 的方法才能实现；
| AAAController | |||
|---|---|---|---|
| BBBService | CCCService | ||
| DDDBO | EEEBO | FFFBO | GGGBO |
参考资料
优先级从高到底
https://blog.devgenius.io/dao-dto-po-so-bo-vo-wtf-6673c9dd5437
https://www.bilibili.com/video/BV18L4y1F7PU
https://blog.csdn.net/weixin_43847283/article/details/121876570