实体与值对象（Entity / Value Object）

用途：判断一个对象该有 ID 还是该整体替换、字段该怎么建模时查阅

定义

构件	判定标准	相等性	可变性
实体（Entity）	有连续标识与生命周期，跨状态变化仍是“同一个东西”	按 ID 比较	可变（状态迁移）
值对象（Value Object）	只关心“是什么值”，无独立生命周期	按全部属性比较	不可变，修改即整体替换

一个可用的三问法：去掉 ID 还能区分两个对象吗？它会独立演化状态吗？业务方会关心“是不是同一个”而不是“值是否相同”吗？ 三问都为“否” → 值对象。

例子：账户余额、金额、地址、时间段、经纬度、订单行（多数情况下）是值对象；账户、订单、合同、用户是实体。

把一切都建成带 ID 的实体，会带来三类成本：状态可被局部修改因而不变式难守护；相等性判断依赖 ID 而忽略内容差异；对象图庞大、加载与比较昂贵。

值对象用不可变 + 整体替换换取三个好处：天然线程安全、可直接作为参数与返回值传递、相等性可预期因而便于缓存与去重。

形态	做法	代价
嵌入列	值对象字段展开成所属表的多个列	表变宽；查询某属性方便
JSON 列	整体序列化存一列	无法按内部字段检索；需要 Schema 版本管理
独立表	值对象存表但只通过根访问	多一次关联；对“值”语义不友好
语言级不可变	Java `record`、Kotlin `data class`、`final` 字段	需要构造期校验配套
基础类型封装	用 `Money` 取代 `BigDecimal`，把币种约束进类型	初期样板代码多

开源参考：Joda-Money、javax.money（Moneta）示范金额值对象；Java record 与 Avaje / MapStruct 支撑不可变建模与转换；Hibernate 的 @Embeddable 处理嵌入形态。

相等性：实体按 ID 比较时，同一聚合在两个会话中可能是不同实例，需要正确实现 equals/hashCode（用 ID，且处理未持久化时 ID 为空的情况）。
集合语义：ORM 的持久化集合会延迟加载并可能被外部直接修改，破坏聚合封装。常见做法是内部持有集合、对外返回不可变副本。
值对象变更检测：不可变对象整体替换天然可检测；若实现了可变值对象，ORM 可能漏掉变更。