值对象重构的核心是通过定义不可变、语义明确、可复用的业务最小单元，重新划定领域边界并切断引用泥潭。需剔除伪值对象，统一跨层数据表达，消除中间转换层，使值对象成为业务语言与代码的一致载体。
重构核心领域模型中的值对象，不是为了“替换一个类”，而是借它撬动整个领域边界的重新定义。关键不在值对象本身，而在它所承载的业务语义是否被清晰、不可变、可复用地表达出来。一旦值对象真正成为业务概念的最小稳定单元，它就能自然隔离外部对实体内部结构的直接依赖，从而从架构层切断引用泥潭。
识别并剥离“伪值对象”
很多项目里所谓的“地址”“金额”“时间范围”只是DTO或VO，字段可变、有Setter、能被任意修改——这根本不是DDD意义上的值对象。真正的值对象必须满足：
- 无唯一标识（ID），只由属性组合定义相等性（重写equals/hashCode）
- 创建后不可变（所有字段final，无public setter，构造即完整）
- 业务语义明确（如Money不是float，而是含currency+amount+四舍五入策略的聚合）
- 在多个实体间共享复用（Order、Invoice、Refund都用同一个Money，而非各自定义price字段）
用值对象替代原始类型和数据类引用
常见泥潭源头是：Service层直接操作order.getAddress().getProvince()，或DAO层把Address拆成province/city/district三字段存库。重构时要反向切断：
- 把address字段从Order实体中抽为Address值对象（Address作为Order的属性，而非嵌套多层getter）
- 所有对地址的操作，必须通过Address提供的业务方法（如isInSameRegion(Address other)），而非暴露字段
- 仓储层不再映射Address的字段，而是用自定义Converter或JPA @Embeddable 将其序列化为JSON或结构化字符串
让值对象成为上下文映射的“翻译器”
不同限界上下文对同一概念可能有不同理解（如“客户”在订单上下文是CustomerId，在CRM上下文是CustomerProfile）。值对象可充当轻量级适配层：
- 订单上下文只持有CustomerId（String类型值对象），不引用CRM的Customer实体
- 当需要客户名称时，通过防腐层（Anti-Corruption Layer）调用客户查询服务，返回CustomerName值对象
- 避免跨上下文直接传递Entity或复杂DTO，所有跨边界数据交换都经由精确定义的值对象
配套清理：删掉所有“值对象代理类”和冗余转换逻辑
重构后常残留这类代码：AddressDTO → AddressVO → Address（值对象）。这种链式转换本身就是泥潭信号。应做到：
- 前端/外部系统输入统一走DTO，经工厂或构造函数直接生成值对象（如Address.of(json)）
- 值对象自身负责校验（如postalCode格式、province与city匹配）
- 彻底删除中间层的VO、BO、Form等同质化包装类，让值对象直面输入与输出
不复杂但容易忽略：值对象不是设计出来的，是业务语言反复锤炼出来的。每次产品说“这个地址要支持国际格式”，就该想到Address是不是该拆出CountryCode；每次测试提“金额精度丢失”，就该确认Money是否封装了BigDecimal和舍入规则。它切断的不是代码引用，是模糊沟通和随意假设。
