在Java企业级开发中，PO、VO、DTO、Entity以及ES/Mongo实体是分层架构下不同职责的数据载体。合理区分和使用这些对象有助于实现"数据隔离"和"单一职责"，降低系统耦合度。
- 核心概念与职责
Entity (领域实体/持久化实体)
定义：通常指与数据库表直接映射的对象，特别是在使用JPA/Hibernate等ORM框架时。
特点：包含@Entity、@Table等注解，可能包含业务行为（在DDD中）或仅作为数据容器。它代表了业务领域的核心模型。
场景：Repository层与数据库交互时使用。
PO (Persistent Object, 持久化对象)
定义：与Entity类似，也是与数据库表一一对应的对象，但更常用于MyBatis等非全自动ORM框架语境。
特点：严格匹配数据库字段，通常只有getter/setter，无业务逻辑。在阿里规范中，常推荐统一使用DO (Data Object)来替代PO或Entity，以屏蔽底层ORM差异。
场景：DAO/Mapper层进行CRUD操作时的数据载体。
DTO (Data Transfer Object, 数据传输对象)
定义：用于服务之间、层之间传输数据的对象。
特点：按需封装数据，可能包含多个PO/Entity的部分字段，或者组合多个对象的数据。不包含业务逻辑，主要解决远程调用效率（减少网络传输次数）和数据安全性（隐藏敏感字段如密码）。
场景：Service层内部传输、微服务间Feign/Dubbo调用、Controller到Service的参数传递。
VO (View Object, 视图对象)
定义：专门用于向前端展示数据的对象。
特点：字段格式符合前端需求（如日期格式化后的字符串、状态码对应的中文描述）。可能包含多个DTO或BO的数据聚合。
场景：Controller层返回给前端的数据响应。
ES/Mongo 实体
定义：针对非关系型数据库（Elasticsearch, MongoDB）的文档对象。
特点：
ES Doc：对应ES中的Index/Document，通常包含@Document注解，字段设计需考虑搜索性能（如分词、索引类型）。
Mongo Doc：对应MongoDB中的Collection/Document，结构灵活，可能嵌套复杂对象。
场景：搜索引擎查询、日志存储、非结构化数据存储。
- 数据流转全景图
在一个典型的Web请求处理流程中，数据对象的转换路径如下：
请求阶段：前端发送JSON -> Controller接收 -> 转换为 DTO (或Param) -> 传给Service。
业务处理：Service层接收 DTO -> 转换为 Entity/PO -> 调用Repository。
持久化/查询：Repository使用 Entity/PO 与数据库交互；若涉及搜索，则使用 ES Entity 与ES交互。
响应阶段：Repository返回 Entity/PO -> Service层组装业务逻辑，可能结合其他数据生成 DTO -> Controller将 DTO 转换为 VO -> 返回给前端。
- 包结构命名建议
为了保持代码清晰，建议在项目结构中通过包名区分这些对象。一种推荐的架构是基于领域驱动设计（DDD）思想，以domain为顶级包：
com.company.project.domain
├── entity // 核心领域实体 (对应数据库表, JPA Entity)
├── po // 持久化对象 (MyBatis PO, 或与entity合并)
├── dto // 数据传输对象 (服务间、层间传输)
├── vo // 视图对象 (前端展示)
├── es // ES文档对象 (Elasticsearch映射)
└── mongo // Mongo文档对象 (MongoDB映射)
为什么不建议统一放在pojo或entity包下？
pojo是一个技术术语，无法体现业务用途，混放会导致职责不清。
entity语义过窄，VO和DTO显然不是实体，强行放入会造成理解混乱。
使用domain作为顶层，子包区分类型，既符合业务视角，又具备良好的扩展性。
- 关键区别总结
对象类型 核心职责 典型层级 是否包含业务逻辑 备注
Entity 数据库映射/领域模型 Repository/Domain 可能包含(D DD) JPA常用
PO 数据库记录映射 DAO/Mapper 否 MyBatis常用，阿里规范推荐用DO
DTO 跨层/跨服务数据传输 Service/Controller 否 解耦内部结构，提高传输效率
VO 前端页面展示适配 Controller/View 否 格式化数据，隐藏敏感信息
ES/Mongo 非关系型数据存储 Search/NoSQL Repo 否 针对特定中间件优化的文档结构
- 最佳实践提示
严禁直接暴露Entity/PO给前端：这会导致数据库结构变更直接影响前端，且容易泄露敏感字段（如password_salt）。必须经过VO转换。
DTO与VO的界限：在简单项目中，DTO和VO可以合并；但在复杂系统中，建议分离。DTO关注"传输什么数据"，VO关注"怎么展示数据"。
对象转换工具：由于层级间需要频繁转换（Entity <-> DTO <-> VO），建议使用MapStruct、BeanUtils等工具简化代码，避免手动编写大量的getter/setter赋值语句。
ES/Mongo实体的独立性：不要试图让一个类同时满足MySQL和ES的映射需求，因为两者的字段类型、注解要求差异巨大。应分别定义独立的实体类。