在领域驱动设计（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()——这会将基础设施逻辑侵入领域模型，模糊分层边界。
这些做法看似“严谨”，实则增加了不必要的复杂性，得不偿失。
关键原则总结
| 应用场景 | 推荐策略 |
|---|---|
| 值对象构造 | 使用显式 if + IllegalArgumentException，确保非法状态无法存在 |
| 外部输入（API/CLI/文件） | 使用 ja vax.validation 注解 + 框架自动校验（如 Spring @Valid） |
| 数据库读取后重建 | 视信任程度而定：若 DB 数据可信，可跳过二次校验；若需兜底，应在仓储层或应用服务中统一校验（非值对象内部） |
| 类型安全增强（进阶） | 可定义 UntrustedSize（含验证方法）与 Size（已验证）两个类型，借助编译器强制校验流程 |
最终，DDD 的价值不在于堆砌注解，而在于用代码清晰表达业务约束。让 Size.ofBytes(-1) 在编译期虽无法拦截，但在运行期第一时间失败并给出明确的语义错误——这比任何反射式验证都更可靠、更高效、更贴合领域驱动设计的核心精神。
