受检异常不应出现在领域层，而应限于应用层入口作为流程守门人；领域层需用非受检领域异常（如invalidwaybillexception）表达业务违规，并通过仓储异常翻译、sealed接口、私有构造函数等机制实现ddd契合的强制约束。
受检异常本身不是ddd的组成部分，也不直接参与领域建模或限界上下文划分。在java中，受检异常（checked exception）要求调用方显式处理或声明抛出，它本质是一种编译期强制约束机制——但若滥用，反而会破坏领域层的纯粹性与可测试性，与ddd“聚焦业务本质”的原则相悖。
领域层应规避受检异常
领域对象（实体、值对象、聚合根）和领域服务的核心职责是表达业务规则与不变量，而非处理I/O、网络或事务失败等基础设施问题。让领域方法抛出IOException或SQLException，等于把技术细节泄漏进业务模型，违背分层架构中“领域层不依赖任何外部设施”的设计契约。
- 聚合根校验运单号格式、重量阈值、收发地址有效性等，应通过返回
Result<t></t>或抛出**非受检的领域异常**（如InvalidWaybillException）来表达业务违规； - 这类异常继承自
RuntimeException，无需强制捕获，便于单元测试快速验证业务逻辑，也符合“领域行为即契约”的建模思想； - 真正需要强约束的，是**应用层**对关键操作的兜底——例如创建运单必须确保幂等、状态跃迁不可逆、并发更新需校验版本号。
用应用服务+命令总线强化防错网
超大型物流系统中，“无锁”不等于放弃一致性，而是用更可控的手段替代数据库行锁。受检异常可在应用服务入口处作为**流程守门人**使用：
- 定义
CreateWaybillCommand，由应用服务接收并校验必填字段、客户信用额度、路由规则匹配度；校验失败时抛出WaybillCreationFailedException（受检），强制上层决定重试、降级或告警； - 命令经总线分发至领域层后，聚合根执行
apply(waybillCreatedEvent)，仅关注自身状态合法性；事件发布后由独立的Saga协调器处理后续动作（如库存扣减、运费计算），失败则补偿； - 这种结构把“强约束”留在命令入口，把“业务决策”留在聚合内，既满足编译期提醒，又不污染领域模型。
仓储与防腐层做异常翻译
当领域层调用仓储持久化运单时，底层可能因DB连接中断、唯一索引冲突等抛出受检异常。此时应在仓储实现类中完成异常翻译：
-
JpaWaybillRepository捕获javax.persistence.OptimisticLockException，转为抛出ConcurrentWaybillUpdateException（非受检）； - 对外暴露的仓储接口
WaybillRepository方法签名不声明任何异常，保持领域层调用干净； - 防腐层（Anti-Corruption Layer）对接第三方轨迹服务时，若HTTP调用失败，同样封装为
TrackingServiceUnavailableException，避免IOException穿透到领域。
编译制约真正该发力的地方
与其靠受检异常约束领域代码，不如把编译强制力用在更关键的位置：
- 用
sealed interface限定运单所有合法状态（Draft、Dispatched、Delivered、Returned），禁止非法状态跃迁； - 聚合根构造函数设为私有，强制走工厂方法
Waybill.create()，确保必经完整性校验； - 关键领域服务接口标注
@DomainService注解，配合编译插件检查是否被非应用层代码直接调用。
这些才是贴合DDD精神的、可持续的“强制约”。
