领域战术核心：解密领域模型多维校验与防线划分

在企业级应用开发中，“数据校验”无处不在。传统的面向过程开发往往将所有的校验逻辑一把抓，堆砌在服务层（Service）甚至控制层（Controller）中。这种混乱的架构会导致领域实体的状态漏洞百出，数据容易被污染。

领域驱动设计（DDD）主张：**“任何一个领域模型实例在生命周期的任何阶段，都必须处于业务一致性状态（Invariants）”**。为了达成这一目标，DDD 建议将纷繁复杂的校验规则分流，由外向内构筑**“三道校验防线”**，让各层组件各司其职，保证核心领域层的绝对纯净。

本文将系统拆解领域校验的三道防线架构设计、防线职责边界对比、以及 Java 契约代码的开发实战。

一、 核心范式：多维校验的三道防线分工对比

不同类型的业务规则应当被拦截在不同的防御前线，从而实现职责的最小解耦：

二、 领域校验多维防线流转判定拓扑

当一个外部提交的表单数据企图注入并修改领域模型时，三道防线的数据校验判定拓扑如下：

      [ 客户端提交注册表单数据 (UserRegisterDTO) ]
                           │
                           ▼ 【 第一道防线：格式防线 (Controller) 】
                ( @NotBlank / 邮箱正则校验 )
                           ├─ (校验失败) ──> 响应 HTTP 400 Bad Request
                           │
                           ▼ (格式正确，调用领域工厂重建)
         【 第二道防线：实体自闭环防线 (Value Object Constructor) 】
                ( 校验属性自相矛盾，如起止时间错乱 )
                           ├─ (校验失败) ──> 抛出 IllegalArgumentException
                           │
                           ▼ (自闭环合理，进入应用服务编排)
         【 第三道防线：业务规格防线 (Domain Service / Spec) 】
                ( 查询数据库比对: 邮箱是否全局唯一 )
                           ├─ (冲突失败) ──> 抛出 BusinessException
                           │
                           ▼ (全防线通过)
                   【 写入数据库落盘 】

三、 代码实战：三道防线代码落地规范

以下代码展示了如何在订单微服务中，按职责层级干净地划分并开发三道校验防线：

1. 第一道防线：接口层格式拦截（Controller Layer）

package com.company.sales.api;

import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.*;
import javax.validation.constraints.*;

@RestController
@RequestMapping("/orders")
@Validated
public class OrderController {

    @PostMapping
    public void createOrder(@RequestBody @Validated OrderRequest request) {
        // 请求进入即触发第一道防线：数据格式及非空校验
        System.out.println("[First Line Pass] 请求数据格式合法！");
    }

    public static class OrderRequest {
        @NotBlank(message = "商品编号不能为空")
        private String sku;

        @Min(value = 1, message = "购买数量必须大于等于1")
        private int quantity;

        // Getters and Setters
    }
}

2. 第二道防线：值对象与聚合构造器自闭环（Domain Layer）

package com.company.sales.domain.model;

/**
 * 购买时间段值对象（自我捍卫不变性约束）
 */
public final class PurchasePeriod {
    private final long startTimestamp;
    private final long endTimestamp;

    public PurchasePeriod(long start, long end) {
        // 第二道防线：在构造器中直接防御自相矛盾的无效状态
        if (start >= end) {
            throw new IllegalArgumentException("开始时间必须早于结束时间！");
        }
        this.startTimestamp = start;
        this.endTimestamp = end;
    }
}

3. 第三道防线：领域服务规格校验（Domain Layer）

package com.company.sales.domain.service;

import com.company.sales.domain.model.SalesOrder;
import com.company.sales.application.repository.OrderRepository; // 修正包路径

/**
 * 订单领域服务
 * 职责：承担需要查询库表比对的第三道防线逻辑
 */
public class OrderDomainService {

    private final OrderRepository orderRepository;

    public OrderDomainService(OrderRepository repository) {
        this.orderRepository = repository;
    }

    /**
     * 校验订单全局重复性
     */
    public void validateOrderUniqueness(SalesOrder order) {
        // 第三道防线：需要跨聚合、跨网络或查询数据库的全局一致性校验
        boolean exists = orderRepository.existsByOrderId(order.getOrderId());
        if (exists) {
            throw new IllegalStateException("该订单号在系统中已存在，拒绝重复提交！");
        }
    }
}

四、 总结

领域模型的多维防线校验机制，是保障复杂微服务系统数据绝对纯净、实现高可靠建模的“三维防火墙”。

It 通过**将校验规则按物理层级分流，彻底解决了将所有规则塞在 Service 层带来的面条式代码痛点；并依靠值对象的强构造校验，赋予了领域实体自我防御的能力，实现了聚合根内部的绝对强一致状态**。掌握这三道防线的划分边界与校验逻辑，是进行企业级业务模型开发、重构杂乱代码、开发高质量 DDD 战术代码 of 核心看家本领！