Java业务建模中，基本类型与包装类命名须体现语义差异：基本类型表确定值（如userAge），包装类表可空业务含义（如estimatedUserAge、preferredChannelId），DTO/VO统一用包装类并按业务域命名，禁用技术后缀，优先枚举强化语义。
业务建模中，Java 基本类型与包装类的命名不是单纯语法问题，而是语义表达和可维护性的关键环节。核心原则是：**用名字讲清“它是什么”和“它为什么能为 null”**。基本类型（如 int）天然不可为 null，代表确定值；而包装类（如 Integer）可为 null，天然承载“缺失、未设置、不适用”等业务语义。命名必须反映这一本质差异。
字段命名要体现可空性与业务意图
当字段在业务上允许缺失或暂未赋值时，必须使用包装类，并在变量名中暗示其可空特性：
-
用明确动词或状态词前缀/后缀：如
appliedDiscountAmount（Double）比discount更清晰；preferredContactMethod（String）已隐含可空，若用Integer表示渠道编号，可命名为preferredChannelId—— “Id” 后缀自然关联主键/外键语义，也暗示可能为空 -
避免模糊缩写或纯技术名：不写
intCount或userAgeInt；应写userAge（int，确定存在）或estimatedUserAge（Integer，估算值，可能未知） -
对布尔含义字段慎用
booleanvsBoolean：如isVerified（boolean）表示“已验证/未验证”二元状态；而verificationStatus（Boolean）则暗示“待验证、已通过、已拒绝”三态，此时更建议用枚举，但若受限于老系统或简单场景，用Boolean并配以描述性名称是合理妥协
DTO/VO 层统一用包装类，命名保持语义一致性
数据传输对象（DTO）、视图对象（VO）面向外部交互，需兼容空值、JSON 序列化及前端可选字段。即使业务上“理论上必填”，也推荐全部使用包装类，并按业务域命名：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
orderAmount（BigDecimal，非double）—— 金额必须精确，且可能为空（如草稿订单） -
shippingDeadline（LocalDateTime，虽非包装类但同理）—— 时间点可选，命名不含 “Optional” 或 “Nullable”，靠类型+业务词传达意图 -
couponCode（String）—— 字符串本身可空，无需额外修饰；若业务上“优惠码仅限新用户填写”，命名newUserCouponCode比couponCodeOpt更直接
避免在命名中暴露技术细节
不把“Wrapper”“Obj”“Value”等技术词塞进变量名。命名焦点永远是业务角色：
立即学习“Java免费学习笔记（深入）”；
- ❌
userIdInteger、priceWrapper、statusBoolean - ✅
userId（Long）、unitPrice（BigDecimal）、isActive（Boolean） - 理由：
userId本身就是 ID，ID 在数据库和业务中天然可空；unitPrice是单价概念，单价可能未录入；isActive是状态标识，状态可能未初始化
配合常量与枚举强化语义
当包装类用于表示有限取值范围时，优先用枚举；若必须用包装类（如对接弱类型接口），可通过常量辅助说明：
- 定义
public static final Integer STATUS_PENDING = 0;配合字段orderStatus（Integer），比硬编码0或命名statusInt更可靠 - 对金额、数量等数值型字段，可在类级注释或 Javadoc 中注明单位与精度要求，例如：
/** 单位：分，精确到个位，-1 表示不参与计价 */ private Integer itemPoints;
