TLDR;

O padrão facade cria uma interface simplificada em torno de APIs como Stripe para encapsular complexidade e reduzir acoplamento no código.. Integrar diretamente com APIs de terceiros força o código a lidar com detalhes específicos como customers e payment intents, gerando bagunça e dificultando mudanças futuras.. Para evitar vazamento de objetos de APIs, o facade deve atuar como um boundary retornando resultados próprios desacoplados em vez de tipos específicos do provedor.

Resumo

O vídeo explica o padrão de projeto Facade usando a integração com o Stripe como exemplo. O código direto que lida com pagamentos cria forte acoplamento, pois espalha detalhes de implementação do Stripe por toda a lógica de negócio, como criação de clientes, payment intents e tratamento de erros específicos. Isso dificulta a manutenção, a troca de provedor e os testes. O Facade resolve o problema ao fornecer uma interface simplificada, mas muitos cometem o erro de ainda retornar objetos do Stripe, mantendo o acoplamento. A solução correta é fazer do Facade uma verdadeira fronteira: ele encapsula toda a complexidade, converte respostas e erros em objetos próprios da aplicação (como um PaymentResult) e expõe apenas o que o domínio precisa. Assim, a lógica de negócio fica completamente desacoplada, facilitando manutenção, testes com mocks e futuras substituições de bibliotecas externas. O mesmo princípio vale para qualquer integração com APIs ou frameworks.