DDD值对象验证时机与最佳实践：构造解耦与输入边界校验

在领域驱动设计（DDD）中，值对象（如 Size）必须通过构造过程确保自身内在一致性；ja vax.validation 不应在值对象内部调用，而应在外部输入解析或命令处理阶段统一完成校验，从而维护值对象的不可变性与领域纯净性。

值对象的核心契约归根结底体现在三个方面：自我验证、不可变性以及概念完整性。以 Size 为例，其本质约束非常清晰——字节数必须为正整数。那么验证逻辑究竟应该放在哪里？显然不应在运行时依赖外部 Validator 触发，而应当内聚于构造过程本身。简而言之：让非法状态根本无从构造。

✅ 正确做法：构造时防御性验证（推荐方案）

@Getter@EqualsAndHashCode@RequiredArgsConstructor(access = lombok.AccessLevel.PRIVATE)public class Size {    private final long bytes;    public static Size ofBytes(long bytes) {        if (bytes <= 0) {            throw new IllegalArgumentException("Size must be greater than zero");        }        return new Size(bytes);    }    public static Size ofKilobytes(long kilobytes) {        return ofBytes(kilobytes * 1024L); // 防止 int 溢出，显式使用 long    }    public static Size ofMegabytes(long megabytes) {        return ofBytes(megabytes * 1024L * 1024L);    }}

这种方案的优势十分显著：构造即校验，彻底杜绝非法实例的生存空间；完全无需引入任何外部框架（无需依赖 ja vax.validation 或 Validator）；严格遵循 DDD 值对象“保证不变式”的设计原则；同时具备线程安全、可序列化以及便于单元测试等特性。

这正是经典 DDD 设计精神的体现——用代码自身表达业务约束，而非依赖注解或反射机制。

⚠️ ja vax.validation 的合理定位：仅用于外部输入解析层

话说回来，@Min、@Positive 这类注解也并非毫无价值。它们主要服务于DTO、请求参数、表单绑定等外部输入载体，而非针对值对象内部设计。来看一个具体示例：

// Web 层接收参数（Spring Boot 示例）@PostMapping("/documents")public ResponseEntity createDocument(@Valid @RequestBody DocumentRequest request) {    // ✅ 此处 validation 由 Spring 自动触发，校验 request 字段    Size size = Size.ofBytes(request.getSizeInBytes()); // 构造已保证合法    Document doc = Document.builder()            .name(Name.of(request.getName()))            .checksum(Checksum.of(request.getChecksum()))            .size(size)            .build();    return ResponseEntity.ok(documentService.sa ve(doc));}

对应的 DocumentRequest 可以附带验证注解：

public class DocumentRequest {    @NotBlank    private String name;    @NotBlank    private String checksum;    @Positive(message = "Size must be > 0")    private long sizeInBytes; // ← 此处使用 ja vax.validation 校验原始输入    // getters...}

这样一来，外部输入的校验在边界层即可完成，值对象内部无需关心这些基础设施层面的细节。

❌ 不推荐的做法（为何要避免）

有些做法值得警惕：将 Validator 注入值对象内部——这会破坏不可变性，引入框架耦合，违反单一职责原则；在 Size 中保留 @Positive 却不主动触发校验——注解形同虚设，非法构造依旧可以绕过；在领域层（如 Document 构建时）手动调用 validator.validate()——这会将基础设施逻辑侵入领域模型，模糊分层边界。

这些做法看似“严谨”，实则增加了不必要的复杂性，得不偿失。

关键原则总结

最终，DDD 的价值不在于堆砌注解，而在于用代码清晰表达业务约束。让 Size.ofBytes(-1) 在编译期虽无法拦截，但在运行期第一时间失败并给出明确的语义错误——这比任何反射式验证都更可靠、更高效、更贴合领域驱动设计的核心精神。