在DDD中，orElseThrow用于在值缺失时抛出领域专属异常，将校验内聚于领域层，确保不变量成立、错误尽早暴露，并配合工厂方法和链式调用表达复杂业务约束。
在DDD中，领域对象的不变量（invariants）必须始终成立，而 Optional.orElseThrow() 是一种简洁、语义明确的方式，用于在值缺失时主动抛出**领域专属异常**，从而把校验逻辑内聚在领域层，避免将空值处理泄露到应用层或基础设施层。
用orElseThrow替代null检查，守住领域边界
DDD强调“让错误尽早暴露”，而非层层判空。例如一个订单必须关联有效客户：
- ❌ 错误做法：在应用服务里做
if (customer == null) throw new IllegalArgumentException(...) - ✅ 正确做法：在订单构造时，用
customerRepository.findById(id).orElseThrow(() -> new CustomerNotFoundException(id))
这样异常类型是领域相关的（CustomerNotFoundException），消息可包含业务上下文（如“客户ID=123不存在，无法创建订单”），且校验逻辑随领域对象生命周期封装，不依赖调用方记忆。
组合Optional链式调用，表达复杂领域约束
当校验涉及多层嵌套关系时，可串联 map() + flatMap() + orElseThrow()，让代码直译业务规则：
- 订单必须有收货地址，且该地址所属城市必须启用配送服务
- 实现：
Address address = order.getShippingAddress() .flatMap(addr -> cityService.findByCode(addr.getCityCode())) .filter(City::isDeliveryEnabled) .map(city -> order.getShippingAddress().get()) .orElseThrow(() -> new DeliveryUnavailableException(order.getId(), address.getCityCode()));
整个链条天然表达了“地址→城市→配送状态”的业务依赖，失败时抛出带订单ID和城市码的领域异常，便于追踪和补偿。
配合工厂方法，把校验逻辑集中到创建入口
DDD推荐用静态工厂方法（如 Order.create(...)）替代公有构造器。此时 orElseThrow 是校验入口的理想搭档：
- 工厂内部统一加载并验证聚合根所需的所有依赖项
- 所有校验失败都抛出
DomainException子类（如InvalidOrderStateException），而非NullPointerException或IllegalArgumentException - 调用方只需关注“创建成功”或“领域异常”，无需理解底层是否为空
这保证了聚合的一致性边界，也使单元测试只需覆盖合法/非法输入两种场景，无需模拟各种空指针路径。
注意：orElseThrow不是万能补丁，需配合领域建模
过度依赖 orElseThrow 可能掩盖建模缺陷：
- 如果频繁出现“找不到XX”异常，应反思：这个ID是否本不该存在？是否该用值对象替代ID引用？
- 若异常类型过于泛化（如全用
RuntimeException），会削弱领域语义——每个异常应对应一个明确的业务失败原因 - 对非关键可选信息（如客户偏好设置），更适合用
Optional保持其可选性，而非强行转为异常
真正符合DDD的做法，是让 orElseThrow 成为**领域规则落地的自然表达**，而不是绕过建模直奔技术解法的捷径。
