如何在DDD中正确使用javax.validation对值对象进行校验

在DDD实践中，值对象的校验不应侵入其内部结构，而应在创建阶段（如解析外部输入时）由外部验证器统一执行，确保值对象保持不可变、无副作用且专注领域语义。

关于值对象的校验，是个很有意思的话题——尤其在DDD实践中，很多团队容易在这里踩坑。我的判断很明确：校验不应该侵入值对象内部结构，而应该在创建阶段，由外部的验证器统一完成。这样才能让值对象始终保持不可变、无副作用，并且专注于纯粹的领域语义。

具体来说，在领域驱动设计中，像Size这类值对象，它的核心使命是表达领域概念、保证内在一致性与不可变性，而不是去充当校验逻辑的调度中心。因此，如果把一个Validator实例作为字段注入到Size类里——比如写成private final Validator validator——这其实就是一种反模式。这种写法不仅破坏了值对象纯净的数据语义，引入了对基础设施的强耦合，更是背离了“值对象应无行为依赖”这一基本设计原则。

那么，正确的做法是什么？很简单：校验发生在值对象构建之前，或者构建后立即执行，由上下文（比如应用服务、API控制器或解析器）负责，而不是值对象自身来操心这件事。

来看一个符合DDD原则的实践示例：

// 值对象定义（纯净、无框架依赖）
@Getter
@EqualsAndHashCode
@RequiredArgsConstructor(access = lombok.AccessLevel.PRIVATE)
public class Size {
    @Min(value = 1, message = "Size must be greater than zero")
    private final long bytes;

    public static Size ofBytes(long bytes) {
        return new Size(bytes);
    }

    public static Size ofKilobytes(long kilobytes) {
        return new Size(kilobytes * 1024L);
    }

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

这里要特别强调一下：@Min这类注解仅仅是作为元数据声明，它本身不会自动触发校验——真正发挥作用，还得靠JSR-303（ja vax.validation）在运行时显式调用。

那么在哪里触发校验？当然是在校验的入口点，比如REST API层或者命令解析器那里。示例代码如下：

@Service
public class DocumentService {
    private final Validator validator;

    public DocumentService() {
        this.validator = Validation.buildDefaultValidatorFactory().getValidator();
    }

    public Document createDocument(String name, String checksum, long sizeInBytes) {
        Size size = Size.ofBytes(sizeInBytes);

        // ✅ 在可信边界处主动校验（如接收 HTTP 请求后）
        Set> violations = validator.validate(size);
        if (!violations.isEmpty()) {
            String errorMsg = violations.stream()
                .map(ConstraintViolation::getMessage)
                .collect(Collectors.joining("; "));
            throw new IllegalArgumentException("Invalid Size: " + errorMsg);
        }

        return Document.builder()
                .name(new Name(name))
                .checksum(new Checksum(checksum))
                .size(size)
                .build();
    }
}

最后，总结一下这个模式的关键设计要点：

• 校验时机要明确：只对来自外部（比如HTTP请求、消息队列、文件导入）的未信任输入执行校验；从数据库加载或内部构造的值对象，默认视为已验证。当然，你也可以考虑引入TrustedSize/UntrustedSize这样的类型来区分，在编译期就强化契约。
• 对值对象保持零侵入：Size里不持有Validator，不暴露validate()方法，不抛出校验异常——它只负责一件事：“只要存在，就是合法的”。
• 分层职责要清晰：应用层或接口适配层来承担校验责任。这其实就是“Parse, don’t validate”理念的体现——先把外部输入解析为领域类型，再进行集中验证。
• 性能和可测性都要兼顾：验证逻辑集中在一处，便于单元测试；同时也能避免在高频调用路径（比如getter方法）中触发反射校验，拖慢系统性能。

遵循这个模式，你的Document实体以及它所组合的值对象（Name、Checksum、Size），才能真正成为轻量、稳定、可复用的领域基石，而不是被框架细节拖累的“半领域半基础设施”混合体。这才是领域设计的正确姿态。