在 DDD 中，值对象（如 Size）应通过构造确保内在一致性；javax.validation 不应在值对象内部调用，而应在外部输入解析或命令处理阶段统一验证，以保持值对象的不可变性与纯净性。
在 ddd 中，值对象（如 size）应通过构造确保内在一致性；`javax.validation` 不应在值对象内部调用，而应在外部输入解析或命令处理阶段统一验证，以保持值对象的不可变性与纯净性。
值对象（Value Object）的核心契约是自我验证、不可变且概念完整。以 Size 为例，其本质约束只有一个：字节数必须为正整数。因此，验证逻辑不应延迟到运行时靠外部 Validator 触发，而应内聚于构造过程本身——即：让非法状态根本无法构造出来。
✅ 正确做法：构造时防御性验证（推荐）
@Getter
@EqualsAndHashCode
@RequiredArgsConstructor(access = lombok.AccessLevel.PRIVATE)
public class Size {
private final long bytes;
public static Size ofBytes(long bytes) {
if (bytes <p>✅ 优势： </p>
- 构造即校验，杜绝非法实例存在；
- 无依赖（不引入 javax.validation 或 Validator）；
- 符合 DDD 值对象“保证不变式”的设计原则；
- 线程安全、可序列化、便于单元测试。
⚠️ javax.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.save(doc));
}
其中 DocumentRequest 可携带验证注解：
public class DocumentRequest {
@NotBlank
private String name;
@NotBlank
private String checksum;
@Positive(message = "Size must be > 0")
private long sizeInBytes; // ← 此处用 javax.validation 校验原始输入
// getters...
}
❌ 不推荐的做法（为何要避免）
- 将 Validator 注入值对象内部：破坏不可变性、引入框架耦合、违反单一职责；
- 在 Size 中保留 @Positive 但不主动触发校验：注解形同虚设，无法阻止非法构造；
- 在领域层（如 Document 构建时）手动调用 validator.validate()：将基础设施逻辑侵入领域模型，模糊分层边界。
? 关键原则总结
| 场景 | 推荐策略 |
|---|---|
| 值对象构造 | 使用显式 if + IllegalArgumentException，确保非法状态无法存在 |
| 外部输入（API/CLI/文件） | 使用 javax.validation 注解 + 框架自动校验（如 Spring @Valid） |
| 数据库读取后重建 | 视信任程度而定：若 DB 数据可信，可跳过二次校验；若需兜底，应在仓储层或应用服务中统一校验（非值对象内） |
| 类型安全增强（进阶） | 可定义 UntrustedSize（含验证方法）与 Size（已验证）两个类型，借助编译器强制校验流程 |
最终，DDD 的价值不在于堆砌注解，而在于用代码清晰表达业务约束。让 Size.ofBytes(-1) 在编译期虽不能拦截，但在运行期第一时间失败并给出明确语义错误——这比任何反射式验证都更可靠、更高效、更符合领域驱动精神。
