重构类依赖网络不是消灭Optional，而是防止其加剧循环依赖；应通过限界上下文划分职责、禁用跨模块Optional链式调用、改用事件驱动替代同步链式查询，使Optional回归空值封装本位。
重构核心领域模型的类依赖网络，不是为了消灭 Optional，而是让 Optional 不再成为循环链的“帮凶”。它本身不导致循环依赖，但当被用在错误的位置、承载错误的语义时，会掩盖或加剧已有的隐式耦合。
识别 Optional 掩盖的真实循环路径
Optional 常出现在“查一个东西，再查它关联的东西”这类链式调用中。比如：
- OrderService.findOrder(id) → 返回 Optional<Order>
- Order.getAddress() → 返回 Optional<Address>
- Address.getCity() → 返回 Optional<City>
- City.getProvinceService() → 却注入了 OrderService（为查该城市下最近订单）
表面看是四层 Optional 链式调用，很干净；实际底层是 OrderService ↔ ProvinceService 的双向调用闭环。Optional 只是让 null 安全了，却没打断这个环。
用限界上下文切分职责，把“跨域访问”显性化
真正的解法不在 Optional 写法，而在模型边界。不能让 City 类直接持有对 OrderService 的引用，而应：
- 将“查询某城市下最近订单”明确划归 订单上下文，提供 OrderQueryPort 接口
- 在 地理上下文 中，只保留 City 的静态属性和本地计算逻辑（如区号、时区）
- 通过防腐层（ACL）接入订单能力：地理模块依赖 OrderQueryAdapter，由框架在运行时注入其实现，而非直连 OrderService
这样，Optional 依然可用在各层内部（如 city.getProvinceCode() 返回 Optional<String>），但跨上下文调用必须走接口+适配器，循环链在编译期就断开。
禁用跨模块的 Optional 链式穿透
允许 order.getAddress().map(Address::getCity)，但禁止 order.getAddress().map(Address::getCity).map(City::getLatestOrder) —— 最后一步已越界。
- 在自研框架中配置编译期检查规则：对返回
Optional<T>的方法，若T属于其他模块，则其map/flatMap方法不可链式调用到该模块的业务方法 - IDE 插件标记此类链式调用为“跨限界上下文污染”，提示改用服务编排（如通过领域事件或应用服务协调）
- 单元测试中扫描
.map(...).map(...).map(...)超过两层的调用链，自动告警并归类为集成风险点
用事件替代同步调用，让 Optional 回归本位
Optional 的天然位置是“单次查询结果的空值封装”，不是“多步协同流程的胶水”。当业务需要组合多个上下文的信息时，应放弃同步链式 Optional，改用事件驱动：
- 订单创建成功后，发布
OrderPlacedEvent - 地理上下文监听该事件，异步更新本地缓存中的“城市活跃订单数”
- 后续查询
city.getActiveOrderCount()就变成纯内存读取，返回Optional<Integer>安全又高效
此时 Optional 又回到了它该在的地方：表达“这个缓存值此刻是否存在”，而不是维系一个脆弱的、隐式的、横跨多个领域的调用链。
