DDD 中 Java 值对象（Value Object）的验证时机与实践指南

DDD中值对象的验证：从构造就“立规矩”

在领域驱动设计的世界里，值对象（Value Object）是一个很特殊的存在——它不应该只是一个简单的数据容器，而是承载着业务概念和价值判断的“一等公民”。设计一个合格的值对象，有个硬性底线：一旦创建出来，它就必须是合法、有效、不可更改的。

这就意味着，验证关卡不能放到运行时的某个遥远角落，靠反射注解来“事后补救”，而是应该在它“出生”的那一刻就强制发生。怎么理解呢？举个例子，一个描述文件大小的 Size 值对象，它的构造过程本身，就应该迫使你传入的数一定是合法的。

所以，我们重构一下传统的写法。去掉那些挂在字段上的 @Min、@Positive 声明式注解，换上更“现实主义”的防御性编程。

@Getter
@EqualsAndHashCode
@RequiredArgsConstructor(access = lombok.AccessLevel.PRIVATE)
public final class Size {
    private final long bytes;

    public static Size ofBytes(long bytes) {
        if (bytes < 1) {
            throw new IllegalArgumentException("Size must be greater than zero: " + bytes);
        }
        return new Size(bytes);
    }

    public static Size ofKilobytes(long kilobytes) {
        return ofBytes(kilobytes * 1024L); // 注意：这里要小心长整型溢出
    }

    public static Size ofMegabytes(long megabytes) {
        return ofBytes(megabytes * 1024L * 1024L);
    }
}

这种写法的好处非常明显：

• 构造即校验：一旦数值不对，连出生的机会都没有，这就从根本上杜绝了非法的实例存在。
• 零反射开销：纯代码逻辑，类型安全又高效。
• 异常语义清晰：IllegalArgumentException 直接告诉你“业务约束被违反”，而不是含糊的校验失败。
• 完全符合DDD契约：值对象必须始终有效，这是建模的第一性原则。

那么，ja vax.validation 到底应该放在哪？

但这里必须澄清一个常见的误解：ja vax.validation 并非值对象的一部分，它从来就不是。它的正确归宿是——外部输入的校验工具。你可以把它看作是系统外围的哨兵，专门在用户请求、API调用、文件解析这些“边界”上干活。

比如在Web层，当用户在JSON请求里丢了一个size字段过来时：

@PostMapping("/documents")
public ResponseEntity createDocument(@Valid @RequestBody DocumentRequest request) {
    // @Valid 触发 ja vax.validation，校验 request 中的 size 字段（比如它得是个正数）
    // 然后，再用校验后的安全数值，通过工厂方法去构造真正的值对象
    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(repository.sa ve(doc));
}

这里有几个关键点值得敲黑板：

• 绝对不要把 Validator 注入到值对象内部：一旦那么做，值对象的纯数据+行为内聚原则就被破坏了，它的不可变性也形同虚设。
• 数值溢出是个大坑：比如 ofKilobytes(1_000_000_000)，如果不处理，kilobytes * 1024L 可能直接溢出成一个负数，而你的校验却通过了。所以，建议在工厂方法里加上 Math.multiplyExact() 这层防护：

public static Size ofKilobytes(long kilobytes) {
    long bytes;
    try {
        bytes = Math.multiplyExact(kilobytes, 1024L);
    } catch (ArithmeticException e) {
        throw new IllegalArgumentException("Size overflow: " + kilobytes + " KB");
    }
    return ofBytes(bytes);
}

• 要区分信任边界：从数据库里读出来的、或者内部服务传过来的 Size 实例，通常默认是可信的，因为它已经通过领域规则保障过了，无需重复校验。校验工作量，请精准地落在“用户输入、API请求、文件解析”这些外部边界上。

总的来说，值对象的验证不是一项运行时可选检查，而是构造时就必须强制履行的契约。把校验逻辑下沉到工厂方法里，既拥抱了DDD的语义，也让系统变得更健壮、更容易维护。而 ja vax.validation 这样的工具，就让它安心地在基础设施层当个警卫吧，别让它污染了整洁的领域模型。