接手一个老系统比写一个新系统难十倍。难在哪儿难在你永远不知道一次普通请求背后到底调了多少东西。我上个月刚接手一个电商后端搜到一个下单接口往下翻了四层数出八个服务、三次 try-catch、一次库存回滚。看到这种代码我第一反应是“能不动就不动”但业务又催着加需求最后我选择了一个所有设计模式里最不激进、却最能救急的解法——门面模式Facade。这个模式的核心思想就是给一堆复杂子系统提供一个统一接口调用方不需要知道里面发生了什么。它不挑语言、不挑场景Java、C、C#、Go都能用属于那种学会一次能吃一辈子饭的设计模式。设计模式这一话题被无数人写过、背过、考过。但门面模式是我见过最容易被低估的一个。很多人觉得它“太简单了就是包一层”可真遇到复杂系统时绝大多数人第一反应还是往调用方里堆代码而不是往门面里收。这篇文章不打算堆概念我用一个真实的下单业务场景把门面模式从原理到实操、从优势到坑全部讲透顺便把软考速记、面试对比、记忆口诀这些高频需求也一并解决。1. 门面模式凭什么是结构型模式里最能救急的一个1.1 先把它放进23种设计模式的坐标系设计模式总共23种按用途分成三类创建型、结构型、行为型。创建型管对象怎么生成行为型管方法怎么协作结构型管类和对象怎么组合。门面模式属于结构型和它同组的还有适配器、桥接、组合、装饰器、享元、代理。结构型模式里绝大多数都要动类与类之间的连接方式。适配器要改写接口形态装饰器要层层包裹对象代理要给原对象安排一个“替身”。唯独门面模式是另类——它完全不改动内部结构只是在外围加一道统一的入口。正是这个特性让它成了老系统重构时的救命稻草。你不需要改子系统的任何一行代码不需要调整类之间的依赖关系只需要在它们和客户端之间插一个门面类复杂度当场就降下来。这一点在遗留系统里价值极大因为老系统的内部代码往往已经烂成一团越改越容易出事最稳妥的做法就是让它维持原样只在外面开一扇干净的门。1.2 复杂系统的真正痛点调用方视角的复杂度爆炸我之前在排查那个下单接口时发现的问题链条是这样的Controller 要拿库存服务、支付服务、物流服务要知道扣库存在先、支付在后、物流最后要关心支付失败时库存要回滚还要处理异常类型、记录日志。调用方承担了不该由它承担的编排职责。打个比方你去餐厅吃饭理想状态是只跟服务员点菜。但如果餐厅不设置服务员你就要自己去厨房找厨师告诉他哪条鱼要清蒸、哪个菜不放辣还得自己端菜、自己催菜中间哪道工序断了你得自己协调。复杂系统的调用方就是那个在厨房里乱转的顾客。门面模式把这种“顾客进厨房”的体验改造成“顾客对着服务员点菜”。调用方只依赖门面门面负责协调后厨里的一切。这个模式下子系统并不知道门面的存在它们只管做好自己的事。这就意味着即使未来某个子系统整体替换只要门面的协议不变调用方一行代码都不用改。1.3 门面模式与依赖倒置的隐性关系很多讲设计模式的文章不会提这一点但它恰恰是面试官最爱深挖的门面模式为什么能降低耦合本质上它实践了依赖倒置原则——调用方不再直接依赖一堆具体的子系统类而是依赖一个高层接口门面。高层模块和低层模块之间多了一个抽象层变化被隔离在这个抽象层里。这个“隐性的依赖倒置”是门面模式能长期稳定运行的理论基础。如果只把门面当做一个普通工具类不考虑接口抽象那门面很容易退化成一个大杂烩。理解这一层关系后你写出来的门面才真正具备架构价值而不仅仅是一个“调度工具”。2. 拆开门面模式三个角色和一条单向通道2.1 门面、子系统、客户端各自的职责边界门面模式的结构非常清晰只有三个角色门面Facade对外提供统一入口内部负责编排子系统。门面是客户端唯一认识的类。子系统Subsystem一组完成实际业务逻辑的类。它们可以被客户端直接调用也可以彼此调用但不需要知道门面的存在。客户端Client只与门面交互不直接操作任何子系统。职责边界划分有个原则门面管流程子系统管业务。流程包括谁先调、谁后调、失败怎么回滚、结果怎么拼装业务包括具体怎么计算库存、怎么扣款、怎么生成物流单。一旦门面里开始出现业务逻辑比如“金额大于1000要走人工审核”它就是越界了这会在后面第5节详细展开。拿库存模块举例。库存服务只关心一个问题库存够不够够就扣减不够就返回 false。至于扣完之后要支付、支付失败要撤销那是门面的事库存服务一概不知。这种单向依赖关系是整个模式最关键的约束——依赖箭头永远从客户端指向门面再指向子系统反向不允许。2.2 门面为什么要“笨”我见过一些“聪明”的门面设计比如门面里做了缓存、做了权限校验、做了埋点统计。看上去功能丰富却违背了门面的本意。门面应该尽量“笨”职责越单一越安全。原因很简单门面是系统里被调用最频繁的一层。每一个请求都会经过它如果门面里塞了缓存和权限逻辑那么任何缓存策略调整、权限规则变更都会波及所有经过门面的业务改动的爆炸半径非常大。而且缓存、权限、埋点这些横切关注点更应该交给独立的中间件或注解去处理而不是和业务编排混在一起。2.3 门面管多宽最少知识原则的落地最少知识原则Law of Demeter经典表达是“只和你的朋友说话不和陌生人说话”。门面模式是这条原则最直观的实践客户端和门面是朋友客户端不认识的子系统统统是陌生人。但门面本身也有管多宽的问题。一个门面对应一个子系统集群还是对应一条完整业务链路我实战中的经验是按业务语义分组不按代码归属分组。比如“订单模块”里有库存、支付、物流三个子系统那么一个 OrderFacade 是合理的如果把“用户模块”的积分服务也塞进 OrderFacade就不合理了——那是另一个门面的事。门面的粒度应当和业务场景的粒度保持一致一个场景一个门面而不是一个模块一个门面。所以门面不是越少越好也不是越多越好。门面太少必然膨胀成“上帝门面”门面太多客户端又要学会在多个门面之间选择复杂度又回来了。合理的粒度是一个门面对应一个高频业务场景内部聚合3到5个子系统。3. 实战一个电商下单业务的门面重构全过程3.1 初始代码一个下单接口调八个服务场景设定用户在前端点“立即购买”后端需要完成扣库存、支付、创建物流单三个动作。这是个很经典的业务链路几乎每个电商项目都会遇到其中库存、支付、物流分属三个不同团队维护。先来看没有门面时的客户端代码。这里我用 Java 演示因为它在设计模式相关话题里受众最广后续会补充其他语言的写法public class OrderController { public String createOrder(String skuId, int quantity, BigDecimal amount) { // 第一步扣库存 InventoryService inventoryService SpringContext.getBean(InventoryService.class); boolean deducted inventoryService.deduct(skuId, quantity); if (!deducted) { throw new RuntimeException(库存不足); } // 第二步支付 long orderId IdGenerator.nextId(); PaymentService paymentService SpringContext.getBean(PaymentService.class); boolean paid paymentService.pay(orderId, amount); if (!paid) { // 这里还要手动回滚库存 inventoryService.restore(skuId, quantity); throw new RuntimeException(支付失败); } // 第三步创建物流单 ShippingService shippingService SpringContext.getBean(ShippingService.class); String trackingNo shippingService.createShipment(orderId); return trackingNo; } }这段代码的问题非常典型Controller 承担了编排职责但 Controller 在 MVC 中的定位是接收 HTTP 请求、返回响应它根本不应该知道这些业务细节。等将来逻辑复杂一些比如加一个优惠券核销、加一个消息推送Controller 的代码会继续膨胀变成一堵永远不敢动的“屎山”。3.2 引入 OrderFacade 之后引入门面后Controller 只需要做一件事调门面。以下是完整重构代码// 子系统一库存 public class InventoryService { public boolean deduct(String skuId, int quantity) { // 真实项目里这里会操作数据库此处省略 return true; } public void restore(String skuId, int quantity) { // 回滚库存 } } // 子系统二支付 public class PaymentService { public boolean pay(long orderId, BigDecimal amount) { // 真实项目里这里会调用第三方支付网关 return true; } } // 子系统三物流 public class ShippingService { public String createShipment(long orderId) { // 真实项目里这里会生成物流单号 return SF orderId; } } // 门面订单门面 public class OrderFacade { private final InventoryService inventoryService; private final PaymentService paymentService; private final ShippingService shippingService; private final AtomicLong orderIdGenerator new AtomicLong(1000L); public OrderFacade(InventoryService inventoryService, PaymentService paymentService, ShippingService shippingService) { this.inventoryService inventoryService; this.paymentService paymentService; this.shippingService shippingService; } public String placeOrder(String skuId, int quantity, BigDecimal amount) { // 1. 扣库存 boolean deducted inventoryService.deduct(skuId, quantity); if (!deducted) { throw new RuntimeException(库存不足); } // 2. 支付失败则回滚库存 long orderId orderIdGenerator.incrementAndGet(); boolean paid paymentService.pay(orderId, amount); if (!paid) { inventoryService.restore(skuId, quantity); throw new RuntimeException(支付失败); } // 3. 创建物流单 return shippingService.createShipment(orderId); } } // 客户端Controller 只依赖门面 public class OrderController { private final OrderFacade orderFacade; public OrderController(OrderFacade orderFacade) { this.orderFacade orderFacade; } public String createOrder(String skuId, int quantity, BigDecimal amount) { return orderFacade.placeOrder(skuId, quantity, amount); } }这一步重构后Controller 里的业务逻辑几乎清零了。将来如果业务链路上要新增加一个“优惠券核销”子系统只需要改 OrderFacade 内部以及新增一个 CouponServiceController 完全不用动。这就是门面模式最直接的好处把变化收敛到一个点上。3.3 逐行对比调用方从一页代码变三行改动前后对照一下对比项重构前重构后调用方代码量十几行含业务判断三行纯转发依赖子系统数量3个还要通过容器查找1个异常处理位置分散在客户端集中在门面新增子系统影响范围客户端必须改只改门面单元测试难度需要 mock 3 个服务只需 mock 门面这个表格里的第六行是我最看重的。重构前测试 Controller必须同时 mock 库存、支付、物流三个服务并且要模拟“支付失败后库存回滚”这种跨服务交互重构后测试 Controller只需要给 OrderFacade 传一个真实或 mock 的对象断言调用对不对即可。门面成了理想的测试边界。3.4 C、C#与Go里的门面长什么样门面模式不绑定语言生态。C 里通常用 Pimpl 惯用法或简单的门面类配合接口指针C# 里则常结合依赖注入容器把门面注册为单例或作用域对象Go 里面没有类继承用 struct 加接口方法组合实现。// C 门面接口示例 class OrderFacade { public: OrderFacade(InventoryService* inv, PaymentService* pay, ShippingService* ship); std::string placeOrder(const std::string skuId, int qty, double amount); private: std::unique_ptrInventoryService inventory_; std::unique_ptrPaymentService payment_; std::unique_ptrShippingService shipping_; };// Go 门面接口示例 type OrderFacade struct { inventory *InventoryService payment *PaymentService shipping *ShippingService } func (f *OrderFacade) PlaceOrder(skuId string, qty int, amount float64) (string, error) { if ok : f.inventory.Deduct(skuId, qty); !ok { return , errors.New(库存不足) } orderId : f.payment.Pay(amount) if orderId { f.inventory.Restore(skuId, qty) return , errors.New(支付失败) } return f.shipping.CreateShipment(orderId), nil }实现语言变了模式的核心没变门面提供一个高层接口把客户端和子系统隔离。你只要抓住“门面管流程、子系统管业务”这条主线用什么语言写出来的结构都是稳的。4. 门面模式与适配器、中介者的边界面试最爱问的三个模式4.1 适配器改口子 vs 门面立门面适配器模式和门面模式经常被搞混因为它们的类图长得很像都是一方持有另一方引用都对外提供统一方法。但二者的出发点完全不同。适配器解决的是接口不匹配问题。客户端期望 USB 接口现有设备是 TypeC 接口适配器把 TypeC 转换成 USB让客户端能直接用。它通常是一对一的转化的是同一个业务能力的数据格式或调用方式。门面解决的是接口过多、流程复杂问题。客户端面对的不只是一个接口不匹配而是三个、五个子系统需要按特定顺序协作门面把这些子系统打包成一个整体对外服务。门面通常是一对多的新定义的接口高于原有接口。一句话区分适配器是“翻译官”门面是“前台接待”。翻译官把一个人的话翻译给另一个人听前台接待帮你协调整个公司内部的所有部门。// 适配器新旧接口互转 public interface NewPaymentService { void pay(String token, double amount); } public class LegacyPaymentService { public void payByCard(String cardNo, String cvv, double amount) { /* old logic */ } } public class PaymentAdapter implements NewPaymentService { private final LegacyPaymentService legacy; public PaymentAdapter(LegacyPaymentService legacy) { this.legacy legacy; } Override public void pay(String token, double amount) { legacy.payByCard(token, ***, amount); // 做一层转化 } }对面这个例子新接口需要 token老接口需要卡号和 cvv适配器负责把新参数翻译成老参数。它服务的对象是两个接口之间的关系这点和门面有着本质区别。4.2 中介者管内部 vs 门面管外部中介者模式属于行为型模式它最容易和门面混淆的地方在于类图看起来都是“星型结构”一个类连接多个类。但方向完全不同。门面模式是客户端到子系统的单向依赖子系统之间不需要经过门面也可以互相调用。中介者模式是多个同事对象之间的网状交互被收拢成星型交互同事对象彼此不再直接引用所有通信都必须经过中介者。翻译成大白话门面管的是“外部怎么访问内部”中介者管的是“内部对象之间怎么互相通信”。门面屏蔽复杂度中介者重构协作方式。实战中最典型的中介者是消息队列。多个微服务不再直接 HTTP 互调而是通过 MQ 收发消息MQ 就是那根中间的“电话线”。这不属于门面的范畴因为门面关注的是给调用方减负而不是给内部通信解耦。4.3 一张表记住三者的区别维度门面模式Facade适配器模式Adapter中介者模式Mediator所属分类结构型结构型行为型核心问题多个子系统对外如何简化接口不匹配如何兼容多个对象之间如何解耦数量关系一对多一对一多对多依赖方向客户端→门面→子系统客户端→适配器→被适配者同事类→中介者→同事类典型场景下单接口统一调度库存、支付、物流老支付接口适配新支付接口聊天室、消息队列、协调者一句话立门面改口子管内部模式重点简化调用收敛变化兼容差异转换接口解耦通信重组协作面试时如果用一句话回答三者的区别我通常这样说适配器让一个接口适配另一个接口门面让多个子系统适配一个客户端中介者让多个对象之间的通信全部改道通过一个协调者。这个回答面试官一般不会再追问细节。5. 门面模式最容易翻车的三个坑上帝门面与被迫开门面5.1 坑一门面方法超过十个变成万事屋门面模式的最大敌人是“懒”。开发者懒得新建类就把所有新功能都塞进门面placeOrder、cancelOrder、queryOrder、refundOrder、updateAddress、applyInvoice……半年下来门面类积累了二十多个方法依赖注入的构造函数参数排了三行。这就是典型的上帝对象God Object反模式。门面原本是简化入口结果变成了一口大锅所有场景都往里倒。改一个发票逻辑联动的可能是订单门面里二十多个方法都依赖的某个字段。解决办法是拆分门面一个场景一个门面。订单链路有OrderPlacementFacade售后链路有OrderRefundFacade查询链路有OrderQueryFacade。拆开之后每个门面都是高内聚、低耦合的。判断标准很简单如果两个门面方法所需要注入的子系统有超过一半重叠说明它们属于同一链路如果重叠很少就该拆。5.2 坑二门面有业务决策违背开闭原则第二个坑比第一个更隐蔽门面里开始出现 if 和 switch并且这些分支和业务规则绑定在一起。比如“如果用户等级是 VIP支付走快速通道否则走普通通道”这种代码很自然就被写在门面里了。这违背了开闭原则因为每次新增用户等级都要改门面的代码而门面恰恰应该是整个系统里最稳定的一层。越稳定的层修改成本越高——因为所有请求都经过它任何改动都要经过完整的回归测试。正确的做法是把等级策略抽象成接口门面通过策略对象去执行而不是用 if 判断。这已经涉及策略模式了它和门面模式并不冲突恰恰是门面模式正确落地的好帮手。5.3 坑三给简单系统硬上门面不是所有场景都需要门面。如果系统只有两个类调用顺序也固定不变硬套门面只会增加一层毫无意义的间接性让代码难以追踪。这个坑在刚学设计模式的人身上尤其常见学完一个模式看什么都像这个模式于是给一个只有两三个类的 CRUD 项目硬套门面。我的经验判断标准有三条三条都满足才上门面客户端需要直接面对至少三个子系统这些子系统之间存在编排顺序或回滚逻辑未来大概率会有新的子系统加入链路。如果只有一条或两条满足我更倾向于直接用模块内的 Service 类组织逻辑不需要特意引入门面。设计模式是工具不是目的。为了模式而模式最后一定会被复杂度和维护成本反噬。6. 门面模式在软考、MVC、微服务里的延伸认知6.1 软考速记与23种模式记忆口诀国内考软考的朋友对门面模式一定不陌生它的别名外观模式在下午题设计模式填空中出现频率不低。软考喜欢考的是“意图”和“适用性”意图为子系统中的一组接口提供一个一致的界面定义了一个高层接口让子系统更容易使用。适用性要为一个复杂子系统提供一个简单接口客户端与抽象类之间存在很大的依赖性希望构建一个层次化的子系统时可以用门面作为子系统的入口。记忆口诀方面23 种设计模式的快速记忆法五花八门。针对结构型模式我总结过一句话“适配桥梁组合饰门面享元代理齐。”这句话把七个结构型模式的名称适配器、桥接、组合、装饰器、门面外观、享元、代理串联在一起。其中门面模式对应的记忆关键词就两个统一入口、外部门面。考试时看到选项里出现“为子系统统一入口”基本就是它了。6.2 MVC中的门面Controller手下的Service层不少人问我MVC 模式里 Controller 调 ServiceService 算不算门面我的看法是Controller 调用的 Service 接口在大多数业务系统中就是门面作用——它对外屏蔽了仓储层、第三方接口、领域服务等一堆细节。严格来说经典 MVC 没有规定 Service 层的存在但在实际的 Java Web 开发中Service 早就成了实际意义上的门面Controller 只认一个 Service 接口Service 内部聚合了 DAO、缓存、MQ、外部 HTTP 客户端等。这个设计让 Controller 保持轻薄正是门面模式思想的落地。可以对比的典型反例是有些项目的 Service 层退化成一个纯转发层Controller 直接注入多个 DAO 和第三方客户端。此时 MVC 架构里的门面职责完全被架空业务逻辑散落在 Controller、DAO 甚至前端里项目必然走向混乱。6.3 微服务时代的门面升级版BFF模式门面模式的价值在单体应用里已经够大到了微服务架构里更没有“退役”。微服务把一个单体拆成几十个服务客户端如果直接跟每个服务交互复杂度爆炸得更厉害先调商品服务再调库存服务再调订单服务还得自己拼装数据。这情景本质上和第一节里那个“进厨房自己找厨师”的顾客没有区别。于是业界提出 BFFBackend for Frontend模式——专门为前端提供聚合接口的后端层。BFF 内部的聚合服务去调多个微服务然后把结果拼装好一次性返回给前端。BFF 就是门面模式在分布式系统下的自然延伸对前端来说BFF 就是一个统一的“门面”它背后的微服务网络是子系统。我把这套类比说给团队新人听的时候他们都觉得门面模式和微服务网关瞬间串起来了。实际上API 网关也可以视为企业级门面对外屏蔽各个服务的真实地址、认证方式和调用协议。门面思想不仅没有过时反而在微服务时代以更重要的形态归来。最后说两句说实话我一开始对门面模式是有点轻视的觉得它“太简单了不配叫做模式”。直到那次维护老系统的经历教会了我设计模式的价值不在难度而在它能不能真正解决现实问题。门面模式用最简单的结构替我把一堆纠缠不清的调用关系收拢得服服帖帖这在实战里的价值远超过那些炫技的写法。如果你也正面对一个调用混乱的复杂系统我的建议是先别急着重构内部代码试着在它的进出口位置加一个门面。你会惊讶地发现仅仅是一个薄薄的接口层就能把调用方从泥潭里拉出来。但记住门面管流程、子系统管业务别让门面变成上帝对象也别给简单系统硬套门面。把握住这两条线门面模式就真正成为你工具箱里的利器了。
门面模式实战：用统一接口驯服复杂系统，从原理到避坑
接手一个老系统比写一个新系统难十倍。难在哪儿难在你永远不知道一次普通请求背后到底调了多少东西。我上个月刚接手一个电商后端搜到一个下单接口往下翻了四层数出八个服务、三次 try-catch、一次库存回滚。看到这种代码我第一反应是“能不动就不动”但业务又催着加需求最后我选择了一个所有设计模式里最不激进、却最能救急的解法——门面模式Facade。这个模式的核心思想就是给一堆复杂子系统提供一个统一接口调用方不需要知道里面发生了什么。它不挑语言、不挑场景Java、C、C#、Go都能用属于那种学会一次能吃一辈子饭的设计模式。设计模式这一话题被无数人写过、背过、考过。但门面模式是我见过最容易被低估的一个。很多人觉得它“太简单了就是包一层”可真遇到复杂系统时绝大多数人第一反应还是往调用方里堆代码而不是往门面里收。这篇文章不打算堆概念我用一个真实的下单业务场景把门面模式从原理到实操、从优势到坑全部讲透顺便把软考速记、面试对比、记忆口诀这些高频需求也一并解决。1. 门面模式凭什么是结构型模式里最能救急的一个1.1 先把它放进23种设计模式的坐标系设计模式总共23种按用途分成三类创建型、结构型、行为型。创建型管对象怎么生成行为型管方法怎么协作结构型管类和对象怎么组合。门面模式属于结构型和它同组的还有适配器、桥接、组合、装饰器、享元、代理。结构型模式里绝大多数都要动类与类之间的连接方式。适配器要改写接口形态装饰器要层层包裹对象代理要给原对象安排一个“替身”。唯独门面模式是另类——它完全不改动内部结构只是在外围加一道统一的入口。正是这个特性让它成了老系统重构时的救命稻草。你不需要改子系统的任何一行代码不需要调整类之间的依赖关系只需要在它们和客户端之间插一个门面类复杂度当场就降下来。这一点在遗留系统里价值极大因为老系统的内部代码往往已经烂成一团越改越容易出事最稳妥的做法就是让它维持原样只在外面开一扇干净的门。1.2 复杂系统的真正痛点调用方视角的复杂度爆炸我之前在排查那个下单接口时发现的问题链条是这样的Controller 要拿库存服务、支付服务、物流服务要知道扣库存在先、支付在后、物流最后要关心支付失败时库存要回滚还要处理异常类型、记录日志。调用方承担了不该由它承担的编排职责。打个比方你去餐厅吃饭理想状态是只跟服务员点菜。但如果餐厅不设置服务员你就要自己去厨房找厨师告诉他哪条鱼要清蒸、哪个菜不放辣还得自己端菜、自己催菜中间哪道工序断了你得自己协调。复杂系统的调用方就是那个在厨房里乱转的顾客。门面模式把这种“顾客进厨房”的体验改造成“顾客对着服务员点菜”。调用方只依赖门面门面负责协调后厨里的一切。这个模式下子系统并不知道门面的存在它们只管做好自己的事。这就意味着即使未来某个子系统整体替换只要门面的协议不变调用方一行代码都不用改。1.3 门面模式与依赖倒置的隐性关系很多讲设计模式的文章不会提这一点但它恰恰是面试官最爱深挖的门面模式为什么能降低耦合本质上它实践了依赖倒置原则——调用方不再直接依赖一堆具体的子系统类而是依赖一个高层接口门面。高层模块和低层模块之间多了一个抽象层变化被隔离在这个抽象层里。这个“隐性的依赖倒置”是门面模式能长期稳定运行的理论基础。如果只把门面当做一个普通工具类不考虑接口抽象那门面很容易退化成一个大杂烩。理解这一层关系后你写出来的门面才真正具备架构价值而不仅仅是一个“调度工具”。2. 拆开门面模式三个角色和一条单向通道2.1 门面、子系统、客户端各自的职责边界门面模式的结构非常清晰只有三个角色门面Facade对外提供统一入口内部负责编排子系统。门面是客户端唯一认识的类。子系统Subsystem一组完成实际业务逻辑的类。它们可以被客户端直接调用也可以彼此调用但不需要知道门面的存在。客户端Client只与门面交互不直接操作任何子系统。职责边界划分有个原则门面管流程子系统管业务。流程包括谁先调、谁后调、失败怎么回滚、结果怎么拼装业务包括具体怎么计算库存、怎么扣款、怎么生成物流单。一旦门面里开始出现业务逻辑比如“金额大于1000要走人工审核”它就是越界了这会在后面第5节详细展开。拿库存模块举例。库存服务只关心一个问题库存够不够够就扣减不够就返回 false。至于扣完之后要支付、支付失败要撤销那是门面的事库存服务一概不知。这种单向依赖关系是整个模式最关键的约束——依赖箭头永远从客户端指向门面再指向子系统反向不允许。2.2 门面为什么要“笨”我见过一些“聪明”的门面设计比如门面里做了缓存、做了权限校验、做了埋点统计。看上去功能丰富却违背了门面的本意。门面应该尽量“笨”职责越单一越安全。原因很简单门面是系统里被调用最频繁的一层。每一个请求都会经过它如果门面里塞了缓存和权限逻辑那么任何缓存策略调整、权限规则变更都会波及所有经过门面的业务改动的爆炸半径非常大。而且缓存、权限、埋点这些横切关注点更应该交给独立的中间件或注解去处理而不是和业务编排混在一起。2.3 门面管多宽最少知识原则的落地最少知识原则Law of Demeter经典表达是“只和你的朋友说话不和陌生人说话”。门面模式是这条原则最直观的实践客户端和门面是朋友客户端不认识的子系统统统是陌生人。但门面本身也有管多宽的问题。一个门面对应一个子系统集群还是对应一条完整业务链路我实战中的经验是按业务语义分组不按代码归属分组。比如“订单模块”里有库存、支付、物流三个子系统那么一个 OrderFacade 是合理的如果把“用户模块”的积分服务也塞进 OrderFacade就不合理了——那是另一个门面的事。门面的粒度应当和业务场景的粒度保持一致一个场景一个门面而不是一个模块一个门面。所以门面不是越少越好也不是越多越好。门面太少必然膨胀成“上帝门面”门面太多客户端又要学会在多个门面之间选择复杂度又回来了。合理的粒度是一个门面对应一个高频业务场景内部聚合3到5个子系统。3. 实战一个电商下单业务的门面重构全过程3.1 初始代码一个下单接口调八个服务场景设定用户在前端点“立即购买”后端需要完成扣库存、支付、创建物流单三个动作。这是个很经典的业务链路几乎每个电商项目都会遇到其中库存、支付、物流分属三个不同团队维护。先来看没有门面时的客户端代码。这里我用 Java 演示因为它在设计模式相关话题里受众最广后续会补充其他语言的写法public class OrderController { public String createOrder(String skuId, int quantity, BigDecimal amount) { // 第一步扣库存 InventoryService inventoryService SpringContext.getBean(InventoryService.class); boolean deducted inventoryService.deduct(skuId, quantity); if (!deducted) { throw new RuntimeException(库存不足); } // 第二步支付 long orderId IdGenerator.nextId(); PaymentService paymentService SpringContext.getBean(PaymentService.class); boolean paid paymentService.pay(orderId, amount); if (!paid) { // 这里还要手动回滚库存 inventoryService.restore(skuId, quantity); throw new RuntimeException(支付失败); } // 第三步创建物流单 ShippingService shippingService SpringContext.getBean(ShippingService.class); String trackingNo shippingService.createShipment(orderId); return trackingNo; } }这段代码的问题非常典型Controller 承担了编排职责但 Controller 在 MVC 中的定位是接收 HTTP 请求、返回响应它根本不应该知道这些业务细节。等将来逻辑复杂一些比如加一个优惠券核销、加一个消息推送Controller 的代码会继续膨胀变成一堵永远不敢动的“屎山”。3.2 引入 OrderFacade 之后引入门面后Controller 只需要做一件事调门面。以下是完整重构代码// 子系统一库存 public class InventoryService { public boolean deduct(String skuId, int quantity) { // 真实项目里这里会操作数据库此处省略 return true; } public void restore(String skuId, int quantity) { // 回滚库存 } } // 子系统二支付 public class PaymentService { public boolean pay(long orderId, BigDecimal amount) { // 真实项目里这里会调用第三方支付网关 return true; } } // 子系统三物流 public class ShippingService { public String createShipment(long orderId) { // 真实项目里这里会生成物流单号 return SF orderId; } } // 门面订单门面 public class OrderFacade { private final InventoryService inventoryService; private final PaymentService paymentService; private final ShippingService shippingService; private final AtomicLong orderIdGenerator new AtomicLong(1000L); public OrderFacade(InventoryService inventoryService, PaymentService paymentService, ShippingService shippingService) { this.inventoryService inventoryService; this.paymentService paymentService; this.shippingService shippingService; } public String placeOrder(String skuId, int quantity, BigDecimal amount) { // 1. 扣库存 boolean deducted inventoryService.deduct(skuId, quantity); if (!deducted) { throw new RuntimeException(库存不足); } // 2. 支付失败则回滚库存 long orderId orderIdGenerator.incrementAndGet(); boolean paid paymentService.pay(orderId, amount); if (!paid) { inventoryService.restore(skuId, quantity); throw new RuntimeException(支付失败); } // 3. 创建物流单 return shippingService.createShipment(orderId); } } // 客户端Controller 只依赖门面 public class OrderController { private final OrderFacade orderFacade; public OrderController(OrderFacade orderFacade) { this.orderFacade orderFacade; } public String createOrder(String skuId, int quantity, BigDecimal amount) { return orderFacade.placeOrder(skuId, quantity, amount); } }这一步重构后Controller 里的业务逻辑几乎清零了。将来如果业务链路上要新增加一个“优惠券核销”子系统只需要改 OrderFacade 内部以及新增一个 CouponServiceController 完全不用动。这就是门面模式最直接的好处把变化收敛到一个点上。3.3 逐行对比调用方从一页代码变三行改动前后对照一下对比项重构前重构后调用方代码量十几行含业务判断三行纯转发依赖子系统数量3个还要通过容器查找1个异常处理位置分散在客户端集中在门面新增子系统影响范围客户端必须改只改门面单元测试难度需要 mock 3 个服务只需 mock 门面这个表格里的第六行是我最看重的。重构前测试 Controller必须同时 mock 库存、支付、物流三个服务并且要模拟“支付失败后库存回滚”这种跨服务交互重构后测试 Controller只需要给 OrderFacade 传一个真实或 mock 的对象断言调用对不对即可。门面成了理想的测试边界。3.4 C、C#与Go里的门面长什么样门面模式不绑定语言生态。C 里通常用 Pimpl 惯用法或简单的门面类配合接口指针C# 里则常结合依赖注入容器把门面注册为单例或作用域对象Go 里面没有类继承用 struct 加接口方法组合实现。// C 门面接口示例 class OrderFacade { public: OrderFacade(InventoryService* inv, PaymentService* pay, ShippingService* ship); std::string placeOrder(const std::string skuId, int qty, double amount); private: std::unique_ptrInventoryService inventory_; std::unique_ptrPaymentService payment_; std::unique_ptrShippingService shipping_; };// Go 门面接口示例 type OrderFacade struct { inventory *InventoryService payment *PaymentService shipping *ShippingService } func (f *OrderFacade) PlaceOrder(skuId string, qty int, amount float64) (string, error) { if ok : f.inventory.Deduct(skuId, qty); !ok { return , errors.New(库存不足) } orderId : f.payment.Pay(amount) if orderId { f.inventory.Restore(skuId, qty) return , errors.New(支付失败) } return f.shipping.CreateShipment(orderId), nil }实现语言变了模式的核心没变门面提供一个高层接口把客户端和子系统隔离。你只要抓住“门面管流程、子系统管业务”这条主线用什么语言写出来的结构都是稳的。4. 门面模式与适配器、中介者的边界面试最爱问的三个模式4.1 适配器改口子 vs 门面立门面适配器模式和门面模式经常被搞混因为它们的类图长得很像都是一方持有另一方引用都对外提供统一方法。但二者的出发点完全不同。适配器解决的是接口不匹配问题。客户端期望 USB 接口现有设备是 TypeC 接口适配器把 TypeC 转换成 USB让客户端能直接用。它通常是一对一的转化的是同一个业务能力的数据格式或调用方式。门面解决的是接口过多、流程复杂问题。客户端面对的不只是一个接口不匹配而是三个、五个子系统需要按特定顺序协作门面把这些子系统打包成一个整体对外服务。门面通常是一对多的新定义的接口高于原有接口。一句话区分适配器是“翻译官”门面是“前台接待”。翻译官把一个人的话翻译给另一个人听前台接待帮你协调整个公司内部的所有部门。// 适配器新旧接口互转 public interface NewPaymentService { void pay(String token, double amount); } public class LegacyPaymentService { public void payByCard(String cardNo, String cvv, double amount) { /* old logic */ } } public class PaymentAdapter implements NewPaymentService { private final LegacyPaymentService legacy; public PaymentAdapter(LegacyPaymentService legacy) { this.legacy legacy; } Override public void pay(String token, double amount) { legacy.payByCard(token, ***, amount); // 做一层转化 } }对面这个例子新接口需要 token老接口需要卡号和 cvv适配器负责把新参数翻译成老参数。它服务的对象是两个接口之间的关系这点和门面有着本质区别。4.2 中介者管内部 vs 门面管外部中介者模式属于行为型模式它最容易和门面混淆的地方在于类图看起来都是“星型结构”一个类连接多个类。但方向完全不同。门面模式是客户端到子系统的单向依赖子系统之间不需要经过门面也可以互相调用。中介者模式是多个同事对象之间的网状交互被收拢成星型交互同事对象彼此不再直接引用所有通信都必须经过中介者。翻译成大白话门面管的是“外部怎么访问内部”中介者管的是“内部对象之间怎么互相通信”。门面屏蔽复杂度中介者重构协作方式。实战中最典型的中介者是消息队列。多个微服务不再直接 HTTP 互调而是通过 MQ 收发消息MQ 就是那根中间的“电话线”。这不属于门面的范畴因为门面关注的是给调用方减负而不是给内部通信解耦。4.3 一张表记住三者的区别维度门面模式Facade适配器模式Adapter中介者模式Mediator所属分类结构型结构型行为型核心问题多个子系统对外如何简化接口不匹配如何兼容多个对象之间如何解耦数量关系一对多一对一多对多依赖方向客户端→门面→子系统客户端→适配器→被适配者同事类→中介者→同事类典型场景下单接口统一调度库存、支付、物流老支付接口适配新支付接口聊天室、消息队列、协调者一句话立门面改口子管内部模式重点简化调用收敛变化兼容差异转换接口解耦通信重组协作面试时如果用一句话回答三者的区别我通常这样说适配器让一个接口适配另一个接口门面让多个子系统适配一个客户端中介者让多个对象之间的通信全部改道通过一个协调者。这个回答面试官一般不会再追问细节。5. 门面模式最容易翻车的三个坑上帝门面与被迫开门面5.1 坑一门面方法超过十个变成万事屋门面模式的最大敌人是“懒”。开发者懒得新建类就把所有新功能都塞进门面placeOrder、cancelOrder、queryOrder、refundOrder、updateAddress、applyInvoice……半年下来门面类积累了二十多个方法依赖注入的构造函数参数排了三行。这就是典型的上帝对象God Object反模式。门面原本是简化入口结果变成了一口大锅所有场景都往里倒。改一个发票逻辑联动的可能是订单门面里二十多个方法都依赖的某个字段。解决办法是拆分门面一个场景一个门面。订单链路有OrderPlacementFacade售后链路有OrderRefundFacade查询链路有OrderQueryFacade。拆开之后每个门面都是高内聚、低耦合的。判断标准很简单如果两个门面方法所需要注入的子系统有超过一半重叠说明它们属于同一链路如果重叠很少就该拆。5.2 坑二门面有业务决策违背开闭原则第二个坑比第一个更隐蔽门面里开始出现 if 和 switch并且这些分支和业务规则绑定在一起。比如“如果用户等级是 VIP支付走快速通道否则走普通通道”这种代码很自然就被写在门面里了。这违背了开闭原则因为每次新增用户等级都要改门面的代码而门面恰恰应该是整个系统里最稳定的一层。越稳定的层修改成本越高——因为所有请求都经过它任何改动都要经过完整的回归测试。正确的做法是把等级策略抽象成接口门面通过策略对象去执行而不是用 if 判断。这已经涉及策略模式了它和门面模式并不冲突恰恰是门面模式正确落地的好帮手。5.3 坑三给简单系统硬上门面不是所有场景都需要门面。如果系统只有两个类调用顺序也固定不变硬套门面只会增加一层毫无意义的间接性让代码难以追踪。这个坑在刚学设计模式的人身上尤其常见学完一个模式看什么都像这个模式于是给一个只有两三个类的 CRUD 项目硬套门面。我的经验判断标准有三条三条都满足才上门面客户端需要直接面对至少三个子系统这些子系统之间存在编排顺序或回滚逻辑未来大概率会有新的子系统加入链路。如果只有一条或两条满足我更倾向于直接用模块内的 Service 类组织逻辑不需要特意引入门面。设计模式是工具不是目的。为了模式而模式最后一定会被复杂度和维护成本反噬。6. 门面模式在软考、MVC、微服务里的延伸认知6.1 软考速记与23种模式记忆口诀国内考软考的朋友对门面模式一定不陌生它的别名外观模式在下午题设计模式填空中出现频率不低。软考喜欢考的是“意图”和“适用性”意图为子系统中的一组接口提供一个一致的界面定义了一个高层接口让子系统更容易使用。适用性要为一个复杂子系统提供一个简单接口客户端与抽象类之间存在很大的依赖性希望构建一个层次化的子系统时可以用门面作为子系统的入口。记忆口诀方面23 种设计模式的快速记忆法五花八门。针对结构型模式我总结过一句话“适配桥梁组合饰门面享元代理齐。”这句话把七个结构型模式的名称适配器、桥接、组合、装饰器、门面外观、享元、代理串联在一起。其中门面模式对应的记忆关键词就两个统一入口、外部门面。考试时看到选项里出现“为子系统统一入口”基本就是它了。6.2 MVC中的门面Controller手下的Service层不少人问我MVC 模式里 Controller 调 ServiceService 算不算门面我的看法是Controller 调用的 Service 接口在大多数业务系统中就是门面作用——它对外屏蔽了仓储层、第三方接口、领域服务等一堆细节。严格来说经典 MVC 没有规定 Service 层的存在但在实际的 Java Web 开发中Service 早就成了实际意义上的门面Controller 只认一个 Service 接口Service 内部聚合了 DAO、缓存、MQ、外部 HTTP 客户端等。这个设计让 Controller 保持轻薄正是门面模式思想的落地。可以对比的典型反例是有些项目的 Service 层退化成一个纯转发层Controller 直接注入多个 DAO 和第三方客户端。此时 MVC 架构里的门面职责完全被架空业务逻辑散落在 Controller、DAO 甚至前端里项目必然走向混乱。6.3 微服务时代的门面升级版BFF模式门面模式的价值在单体应用里已经够大到了微服务架构里更没有“退役”。微服务把一个单体拆成几十个服务客户端如果直接跟每个服务交互复杂度爆炸得更厉害先调商品服务再调库存服务再调订单服务还得自己拼装数据。这情景本质上和第一节里那个“进厨房自己找厨师”的顾客没有区别。于是业界提出 BFFBackend for Frontend模式——专门为前端提供聚合接口的后端层。BFF 内部的聚合服务去调多个微服务然后把结果拼装好一次性返回给前端。BFF 就是门面模式在分布式系统下的自然延伸对前端来说BFF 就是一个统一的“门面”它背后的微服务网络是子系统。我把这套类比说给团队新人听的时候他们都觉得门面模式和微服务网关瞬间串起来了。实际上API 网关也可以视为企业级门面对外屏蔽各个服务的真实地址、认证方式和调用协议。门面思想不仅没有过时反而在微服务时代以更重要的形态归来。最后说两句说实话我一开始对门面模式是有点轻视的觉得它“太简单了不配叫做模式”。直到那次维护老系统的经历教会了我设计模式的价值不在难度而在它能不能真正解决现实问题。门面模式用最简单的结构替我把一堆纠缠不清的调用关系收拢得服服帖帖这在实战里的价值远超过那些炫技的写法。如果你也正面对一个调用混乱的复杂系统我的建议是先别急着重构内部代码试着在它的进出口位置加一个门面。你会惊讶地发现仅仅是一个薄薄的接口层就能把调用方从泥潭里拉出来。但记住门面管流程、子系统管业务别让门面变成上帝对象也别给简单系统硬套门面。把握住这两条线门面模式就真正成为你工具箱里的利器了。
