PHP架构里门面模式是啥_通俗理解与应用【说明】_技术教程

门面模式解决复杂子系统调用耦合问题，通过统一入口封装多类协作流程；需依赖注入、动词命名、仅编排不封装逻辑；适用于跨域协作频繁场景，单类或无关联模块不应滥用。

门面模式不是“语法糖”，也不是 Laravel 专属的魔法，它就是一个专门给复杂子系统装上统一操作按钮的设计套路——你不用知道后台调了几个类、连了几个数据库、发了几条消息，只要对 OrderFacade::place() 按一下，事情就办妥了。

门面模式到底解决什么问题？

当你的 PHP 项目里出现这类信号，就该考虑加个门面了：

一个业务动作（比如「用户下单」）要手动 new User、Cart、Inventory、Payment、Notification 五个类再串起来调用
新同事看注册流程，得翻 7 个文件才能搞清数据流向
测试时 mock 对象越来越多，Mockery::mock(InventoryService::class) 都快写成一行诗了
想把支付模块从支付宝换成微信？改完 Payment 类，发现 OrderController 里还藏着三处直接调用

门面不改变子系统本身，只在它们前面立一块操作面板——把分散的入口收拢，把耦合的依赖隔离。

怎么写一个靠谱的门面类？关键三点

别照抄示例里的空壳 Facade 类，真实项目中容易踩这些坑：

别在构造函数里硬 new 子系统：用依赖注入或服务容器获取实例，否则无法单元测试、无法换实现。正确写法是 public function __construct(InventoryService $inventory, PaymentGateway $payment)
方法命名要动词开头、语义完整：用 placeOrder()，别用 doIt() 或 handle()；返回值尽量统一（如总返回 OrderResult 对象），别一半 return true、一半 throw Exception
不封装逻辑，只编排调用：门面里不该有 if-else 业务规则、不该算库存扣减公式、不该拼接短信模板——那些属于子系统职责。门面只负责“先调 A，成功再调 B，失败就回滚 C”

class OrderFacade
{
    public function __construct(
        private InventoryService $inventory,
        private PaymentGateway $payment,
        private NotificationService $notify
    ) {}

    public function placeOrder(array $data): OrderResult
    {
        $order = $this->inventory->reserve($data['items']);
        $payment = $this->payment->charge($order->total);
        $this->notify->sendSuccess($order->id);

        return new OrderResult($order->id, $payment->ref);
    }
}