在日常 Java 后台开发中，良好的命名规范能显著提升代码的可读性、可维护性与协作效率。本文基于实践经验，总结出一套命名规范模板，适用于典型的 Web 后端开发场景。
🌟 命名原则
- 语义清晰：命名要能准确表达其所代表的实体或行为。
- 统一风格：统一使用驼峰命名（CamelCase），类名首字母大写，变量/方法名首字母小写。
- 简洁优雅：避免冗长，拒绝无意义缩写。
- 领域驱动：以业务语言命名，贴合领域模型。
📦 包名规范
1
| com.company.project.module
|
示例：
1
| com.acme.warehouse.outbound
|
🔠 类名规范
| 类型 |
命名后缀 |
示例 |
| 实体类 |
Entity |
OrderEntity, UserEntity |
| DTO类 |
DTO |
UserDTO, CreateOrderDTO |
| VO类 |
VO |
UserVO, TabVO |
| 参数类 |
Param, Request |
LoginRequest, QueryOrderParam |
| 返参类 |
Response, DO |
QueryResultResponse, OrderDO |
| 接口类 |
以功能命名 |
OrderService |
| 实现类 |
Impl |
OrderServiceImpl |
| Mapper接口 |
Mapper |
UserMapper |
| 枚举类 |
Enum |
OrderStatusEnum |
🧩 方法命名规范
增删改查
| 功能 |
方法名前缀 |
示例 |
| 新增 |
create / add |
createOrder() |
| 查询 |
get / list / query |
getOrderById() / listUsers() |
| 更新 |
update / refresh / modify |
updateUserProfile() |
| 删除 |
delete / remove |
deleteOrderById() |
业务行为
- 尽量使用动宾结构，如
shipOrder()、cancelOrder()。
- 特殊行为用动词短语，如
rollbackInventory()、refreshStatusAfterShipping()。
🔧 变量命名规范
| 类型 |
命名风格 |
示例 |
| 基本类型 |
简短语义 |
count, totalAmount |
| 对象实例 |
实体名小写 |
order, userDTO |
| 集合 |
复数形式 |
orders, userList |
| 布尔值 |
is, has, can 前缀 |
isValid, hasPermission |
📄 控制器规范
- 控制器类名：
xxxController
- 路由方法名建议语义化，如：
1
2
| @PostMapping("/create")
public AjaxResult createOutboundOrder(@RequestBody OutboundOrderDTO dto)
|
🧱 DAO 层命名与参数返回规范（重点）
DAO 层是数据持久化访问层，命名与参数结构需统一规范，避免 VO/DTO 混用、职责模糊等问题。
🔹 入参规范
| 场景 |
入参类型 |
示例 |
| 基础查询 |
MyBatis-Plus 自动封装 |
selectById(id) |
| 复杂查询 |
QueryParam / QueryRequest |
QueryOrderParam |
❗ 不再使用 PO 作为术语或命名后缀，基础持久化逻辑由 MyBatis-Plus 提供，Entity 即可满足结构映射需求。
🔹 返回值规范
| 场景 |
返回类型 |
示例 |
说明 |
| 基础查询 |
Entity |
UserEntity, OrderEntity |
由 MyBatis-Plus 提供，直接返回数据库字段映射结构 |
| 复杂查询 |
✅ DO（Data Object） |
OrderDetailDO, WarehouseDO |
用于多表联查、聚合字段等，结构不直接绑定数据库表 |
| 复杂查询 |
✅ QueryResponse |
OrderQueryResponse, UserQueryResponse |
表达请求响应对称性，结构更贴近业务语义 |
✅ DO 全称解释
- DO：
Data Object
- 意指：数据库查询返回的只读结构体，通常用于多表结果、聚合字段等
- 与 Entity 的职责分离，不与数据库直接绑定
❌ 不推荐
- ❌ 使用 VO 作为 DAO 返回结构：职责在于视图展示，不应参与数据访问层逻辑
- ❌ 使用 DTO 作为 DAO 返回结构：DTO 是服务间传输结构，非查询结果结构
🔁 Service 层转换职责（重点）
DTO：用作接口入参、插入/更新结构化输入VO：作为返回结构- DTO -> DAO层的QueryParam和QueryResponse的转换
- DAO层的DO或QueryResponse -> VO的转换
- ❗ Service 层仅负责业务逻辑组织，不应承载转换职责过多，建议结构拆分清晰。可使用 MapStruct / BeanUtil 等工具进行结构转换
💬 总结建议
- 明确每层职责，结构命名与使用语义清晰区分
- 接口层结构：入参DTO、返参VO
- Service层结构：入参DTO，返参VO
- DAO层基础持久化结构：Entity(建议不加Entity后缀，与表名一致)，基于MyBatis-Plus
- DAO层查询结构：入参QueryParam/QueryRequest，返参DO/QueryResponse
命名即抽象，抽象即设计。持续迭代你的命名风格，它反映了你的认知深度和系统设计水平。
欢迎在评论区补充你常用的命名模式或反面案例！