建模真实业务场景需聚焦“谁在做什么、状态怎么变、边界在哪里”三大核心：类设计应体现角色、特征与动作；封装须嵌入业务规则；对象协作要反映真实依赖；数据库映射需保持领域语义清晰。
建模真实业务场景，关键不是把现实照搬进代码，而是抓住“谁在做什么、状态怎么变、边界在哪里”这三个核心。类与对象的映射不是机械对应，而是有取舍、有约束、有职责的设计过程。
从真实事物出发定义类结构
别一上来就写 class User。先问清楚：这个事物在系统里承担什么角色？它有哪些稳定特征和必须响应的动作？
- 比如“订单”，在电商系统中不是一堆字段的集合，而是有明确生命周期的业务实体：它有编号、创建时间、金额、状态（待支付/已发货/已完成）；它能执行“提交”“取消”“发货”“计算总价”等动作
- 再如“库存项”，核心不是“有多少件”，而是“能否扣减”“是否预警”“归属哪个仓库”——这些决定了你要暴露哪些方法，而不是只提供
getQuantity()和setQuantity()
用封装控制状态变更的合法性
属性私有化只是起点，真正重要的是把业务规则嵌入行为中。
- 订单状态不能被外部直接设为
"shipped"，而应通过ship()方法触发：内部检查是否已支付、是否有库存、是否超时，全部通过才更新状态并记录日志 - 用户余额不能直接赋值，而要提供
addBalance(BigDecimal amount)或deductBalance(BigDecimal amount)，并在方法内校验是否为负、是否超过信用额度 - 构造函数强制初始化关键字段：订单号、用户ID、创建时间必须在创建时确定，避免出现“半成品”对象
让对象协作反映业务流程
多个对象之间的引用关系，要体现真实的业务依赖，而不是技术便利。
立即学习“Java免费学习笔记（深入）”；
- 一个订单持有对用户的引用（
private User buyer），但不持有对物流公司的完整实例——只需知道运单号和当前物流状态，避免过度耦合 - 部门与员工是一对多关系，但员工对象里存的是
Department dept引用，部门对象里维护List<Employee> staff，这种双向关联需谨慎管理生命周期，防止内存泄漏或状态不一致 - 理解引用本质：两个变量指向同一订单对象时，调用
orderA.cancel()后，orderB.getStatus()自然返回新状态——这不是bug，是协作的基础
映射数据库时保持领域语义清晰
实体类不是表结构的复刻，而是业务逻辑的载体。
-
@Column(name = "t_order_status")可以存在，但状态字段在Java中应是枚举类型OrderStatus，而非String或int，保证类型安全和可读性 - 金额字段用
BigDecimal，避免浮点误差；时间字段用Instant或带时区的ZonedDateTime，而非Date或long - 不要为了ORM方便而暴露无业务意义的getter/setter。比如不需要
setCreateTime()，因为创建时间应由系统生成且不可修改
