外观模式适合哪些应用场景？

简化版

外观模式适合子系统复杂、调用流程固定、客户端需要简化入口的场景。典型应用包括订单创建流程、支付统一入口、报表生成、文件导出、API Gateway、BFF、后台聚合接口、第三方 SDK 封装和老系统改造。

详细版

常见场景：

1. 多个服务组合成一个业务用例；
2. Controller 需要调用多个业务服务；
3. 前端页面需要聚合多个后端接口；
4. 微服务通过 Gateway/BFF 对外提供统一入口；
5. 第三方 SDK 调用复杂，需要封装；
6. 老系统接口复杂，需要提供新入口；
7. 报表、导出、审批等流程步骤固定；
8. 需要统一鉴权、日志、异常转换；
9. 对外开放 API，想隐藏内部系统结构；
10. 分层架构中需要应用服务层。

不适合的场景是子系统本身很简单，或者调用方确实需要细粒度控制底层能力。

完整版教学

一、订单创建这类复杂业务流程

订单创建通常不是一个简单保存动作。

它可能涉及：

• 用户校验；
• 商品校验；
• 价格计算；
• 优惠券冻结；
• 库存锁定；
• 订单创建；
• 消息发送。

把这些流程封装到 OrderFacade，能让 Controller 更简单。

二、报表和文件导出

报表导出可能涉及：

• 查询数据；
• 组装字段；
• 生成 Excel；
• 上传文件；
• 记录导出任务；
• 发送通知。

调用方只需要：

reportFacade.export(reportRequest);

外观类隐藏内部多个步骤。

三、第三方 SDK 封装

第三方 SDK 可能接口多、参数复杂、异常类型混乱。

可以封装一个：

PaymentFacade
SmsFacade
StorageFacade
MapFacade

业务系统只依赖统一外观，不直接接触复杂 SDK。

四、微服务聚合接口

前端页面经常要展示聚合数据。

例如用户主页需要：

• 用户基本信息；
• 订单数量；
• 优惠券数量；
• 推荐商品；
• 消息提醒。

BFF 或聚合 Facade 可以一次返回页面需要的数据，减少前端多次调用。

五、老系统改造

老系统接口可能命名混乱、参数复杂、调用顺序严格。

外观模式可以在不大改老系统的情况下提供新接口：

NewClient -> LegacyFacade -> OldSubsystem

这样新系统接入更简单，老系统内部可以逐步重构。

六、常见误区与追问

适用场景都具有“调用方不该知道完整步骤”的特征。启动家庭影院要操作5个设备、生成报表要协调查询和格式化、页面聚合要访问多个服务，都可用外观收敛入口。若调用方本来只调用1个稳定接口，再加 Facade 只会产生无意义转发。

检查维度	判定依据
适合	多步骤子系统协作且调用方众多
不适合	单一简单接口或需完全暴露底层能力

心法：当多个调用方重复拼装同一条用例流程时，才是外观出现的信号。

• 误区：第三方 SDK 包装一定是外观模式。 若主要解决接口不兼容，更准确的模式可能是适配器。
• 追问：旧系统改造为何适合 Facade？ 先提供稳定新入口，可把内部迁移和调用方改造解耦。
• 误区：微服务聚合只需并行调用。 还要定义超时、部分失败、缓存与数据一致性。
• 追问：多个客户端需求不同怎么办？ 为 Web、移动端等建立不同 Facade 或 BFF，避免万能参数。
• 追问：怎样确认不是过度设计？ 统计是否有至少2处重复编排，以及子系统变化是否频繁传播到调用方。

七、加强记忆

外观模式适合“调用方不想面对一堆复杂子系统”的场景：订单流程、报表导出、SDK 封装、微服务聚合、BFF、老系统改造都很典型。只要核心诉求是简化入口和隐藏复杂性，就可以考虑外观模式。