受检异常与领域设计，重构物流防错系统

本文深入探讨了在领域驱动设计（DDD）背景下如何合理运用异常机制重构物流运单防错系统，核心观点是：受检异常不应侵入领域层，而应退守至应用层入口作为流程守门人；领域层须通过非受检的领域异常（如InvalidWaybillException）、密封接口、私有构造函数和仓储异常翻译等手段，实现对业务规则与不变量的纯粹、可测试且符合DDD契约的强制约束——既守住编译期的安全底线，又不牺牲领域模型的清晰性与内聚性，真正让技术为业务本质服务。

受检异常本身不是DDD的组成部分，也不直接参与领域建模或限界上下文划分。在Java中，受检异常（checked exception）要求调用方显式处理或声明抛出，它本质是一种编译期强制约束机制——但若滥用，反而会破坏领域层的纯粹性与可测试性，与DDD“聚焦业务本质”的原则相悖。

领域层应规避受检异常

领域对象（实体、值对象、聚合根）和领域服务的核心职责是表达业务规则与不变量，而非处理I/O、网络或事务失败等基础设施问题。让领域方法抛出IOException或SQLException，等于把技术细节泄漏进业务模型，违背分层架构中“领域层不依赖任何外部设施”的设计契约。

• 聚合根校验运单号格式、重量阈值、收发地址有效性等，应通过返回Result或抛出**非受检的领域异常**（如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精神的、可持续的“强制约”。

今天关于《受检异常与领域设计，重构物流防错系统》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！