Spring Boot中@Service互调是否为不良实践？示例适配何种设计模式？

先给结论：完全不算。这是Spring单体应用分层架构里的常规操作，只要每个Service都守住「单一职责」的底线——只处理自己领域内的业务逻辑，就没毛病。比如你示例里的几个Service：ProductService管商品、PayService管支付、DeliveryService管配送，各司其职，OrderService作为订单领域的核心服务，协调这几个依赖完成下单流程，是很典型的业务聚合场景。

你同事提到的外观模式，其实你现在的OrderService已经在干这个事了：

• 外观模式的核心就是给一堆复杂的子系统套个统一入口，让客户端不用关心内部细节，只跟这个入口打交道。
• 你写的createOrder()方法就是这个统一入口，内部把商品查询、支付、配送的逻辑串起来，上层调用方（比如Controller）只需要调用orderService.createOrder()就行，根本不用管背后三个Service是怎么工作的。

额外提几个需要注意的点：

• 别搞循环依赖：比如OrderService依赖ProductService，ProductService又反过来依赖OrderService，这种情况会直接导致Spring容器启动失败，碰到了要么调整业务逻辑，要么用@Lazy临时规避，但你的示例里没这个问题。
• 守住职责边界：别让某个Service越界干活，比如绝不能在ProductService里写支付逻辑，你现在的代码在这点上做得很规范。
• 事务要跟上：如果createOrder()里的几步操作必须保证原子性（比如支付失败了，商品相关操作得回滚），记得给这个方法加@Transactional注解，确保事务一致性。

至于有人觉得服务间互调不好，大概率是把单体的Service和微服务的服务搞混了：微服务里跨服务调用要考虑分布式事务、网络延迟这些问题，但你这是Spring Boot单体应用，Service只是业务逻辑层的组件，互相调用完全合理。

总结：你当前的实现就符合外观模式的设计，是合理且推荐的写法，完全不是什么不良实践。

内容的提问来源于stack exchange，提问作者Jay