Record 自定义构造器实现领域状态校验

Java record 的 compact constructor 是唯一能在对象实例化前执行领域状态校验的合法且强制生效的位置，它天然契合 DDD 中“非法状态绝不允许存在”的核心原则——在这里可安全检查空值、格式、范围及业务规则，抛出 IllegalArgumentException 或 IllegalStateException；但严禁赋值 final 字段，也不支持归一化处理（如 trim），否则编译失败；更关键的是，它在 Jackson（2.15.2+）、JPA/Hibernate（6.0+）及手动 new 等所有创建路径中真实触发，为数据合法性提供全链路兜底，而注解如 @NotBlank 在 record 上形同虚设；面对复杂状态迁移或聚合根生命周期约束时，它虽能力有限，却能以极简方式守住最关键的准入防线。

compact constructor 是唯一能介入 record 构造过程的校验点

record 没有 init 块、没有 post-constructor 钩子，所有组件在 this() 调用后即完成 final 初始化，不可拦截或修改。这意味着：校验逻辑若写在 this() 之后，实例已经构造成功，抛异常也拦不住对象存在；而 compact constructor 是编译器强制要求在 this() 前执行的唯一合法位置，天然契合“领域状态必须合法才允许存在”的 DDD 原则。

校验必须在 this() 调用前完成，且不能赋值字段

常见错误是试图在 compact constructor 中做归一化处理，比如 this.email = email.trim() —— 这会直接编译失败，因为 record 组件是 final，禁止显式赋值。正确做法是只读取参数、检查约束、抛异常：

• 检查空值、格式（如邮箱含 @）、范围（如年龄 0–150）、业务规则（如订单状态只能是 "pending" 或 "shipped"）
• 异常类型统一用 IllegalArgumentException 或 IllegalStateException，避免 checked exception（record 构造器不支持 throws）
• 若需 trim 或 toUpperCase 等标准化，必须用规范构造器（显式写出带参构造并调用 this(...)），但会失去部分自动生成优势，非必要不推荐

Jackson 和 JPA 入库时 compact constructor 会真实触发

很多人误以为加了注解（如 @NotBlank）就够了，但 JSR-303 不强制验证框架调用 compact constructor。实际链路是：

• Jackson 2.15.2+ 启用 RecordModule 后，反序列化 JSON 到 record 会走 compact constructor → 校验立即生效
• JPA/Hibernate 6.0+ 默认使用 canonical constructor，compact constructor 自动参与，无需额外配置
• 手动 new UserDTO(" ", -5) 同样触发 → 所有创建路径被统一兜底
• @NotBlank 等注解在 record 上**不会自动生效**，必须靠构造器内显式校验保底

DDD 场景下容易忽略的边界：聚合根 ID、状态迁移合法性

record 本身无法表达“状态机”语义，但可借助紧凑构造器拦截非法状态跃迁。例如订单从 "created" 直接到 "delivered" 是不允许的：

• 把状态字段声明为枚举（如 OrderStatus status），并在 compact constructor 中检查前序状态（需传入上下文，如上一个状态值）
• 聚合根 ID 若需 UUID 格式，校验逻辑写在 compact constructor 中比依赖 ORM 的 @PrePersist 更早、更可靠
• 注意：record 不能继承，也不能实现复杂的生命周期回调，复杂状态流转建议退回到普通 class，别硬套 record

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。