Facades no Laravel entregam velocidade, mas cobram o preço em acoplamento

Meriéli Manzano — Thu, 14 May 2026 15:15:00 +0000

As Facades do Laravel são algo que o framework disponibiliza e que vejo muitos projetos usando em controllers, services, entities e até mesmo em repositories. Eu pessoalmente já usei e ainda uso Facade, a produtividade inicial é maravilhosa, o código fica enxuto e você entrega valor rápido porque não precisa instanciar, é só usar a Facade direto, é lindo.

Só que tenho refletido sobre uma coisa que não aparece no curto prazo, especialmente quando a aplicação cresce e a manutenção se estende por anos.

Pense num cenário real:

Você tem uma classe de serviço que usa várias outras Facades internas. Funciona perfeitamente bem, até o dia que você precisar reaproveitar aquela lógica num script isolado fora do Laravel. Ou testar aquela classe sem o framework inteiro carregado.

Aí você percebe: a classe não diz o que ela precisa. Você só descobre abrindo o código linha por linha. E cada facade é um fio invisível conectado ao Laravel.

Não é que Facade seja errada. É que elas resolvem um problema (velocidade) e criam outro silencioso (acoplamento implícito). Cada time escolhe seu trade-off. Esse acoplamento forte com o framework vai justamente contra as regras de dependência da Clean Architecture.

Para entender por que, precisamos saber que Facades do Laravel funcionam como “proxies estáticos” que fornecem acesso a objetos registrados no service container. São uma “ponte” entre uma chamada de método estático e a instância real de um objeto, resolvido em tempo de execução pelo container de injeção de dependência do Laravel.

Abaixo separei algumas vantagens e desvantagens que vai te ajudar a decidir quando realmente devemos usá-las.

Vantagens:

Código mais rápido de escrever e mais fácil de ler, acelerando drasticamente o desenvolvimento e a prototipagem.
Facilidade para testar usando shouldReceive() e Fakes para garantir que a lógica real não seja acionada, diferente de métodos estáticos tradicionais. “Obs: Mas já que a IA está criando testes com maestria, será que isso faz realmente a diferença?”
Tem comportamento Singleton, sendo resolvida uma única vez por requisição.
Pode ser usada em qualquer lugar, sem a necessidade de passar dependência manualmente pelo construtor.

Desvantagens:

Acoplamento que não quebra a testabilidade, mas suja as dependências “ou seja, não é declarada a dependência, ela fica implícita e só é descoberta olhando o corpo dos métodos”. O que dificulta manutenção e reuso.
Viola a Inversão de Dependência, a classe depende diretamente de uma implementação concreta ou de uma interface resolvida pela Facade, não de uma abstração definida pelo domínio, injetada de fora.
Lógica acoplada ao Framework, porque Facades só funcionam com o Facade Root inicializado. Se um dia pretender reutilizar aquela classe em um script isolado, pacote PHP puro ou outro framework, precisará reescrever tudo.
Por serem muito convenientes, facilitam a violação silenciosa do SRP: desenvolvedores adicionam novas responsabilidades indiretas sem que o construtor da classe sinalize o inchaço.

Deixo mais dois pontos de atenção que não são necessariamente desvantagens, mas devem ser conhecidos:

Embora sejam testáveis, os mocks são aplicados globalmente – afetam todas as chamadas à facade durante o teste, não apenas uma instância específica. Sem uma limpeza explícita (como clearResolvedInstances() no tearDown), pode haver vazamento de comportamento entre testes. É um ponto de atenção, mas contornável.
A facade não é mais rápida que a injeção direta. Cada chamada paga o custo do __callStatic() e da resolução da chave no container – é tecnicamente mais lenta, mas na prática você nunca vai medir essa diferença.

Facades são ótimas em Controllers, Commands, Jobs (camadas mais próximas da infra). E podem até ser usadas em protótipos e MVPs, são uma excelente escolha para garantir velocidade de entrega.

Já nas camadas de domínio, serviços de aplicação, objetos de valor, entidades... faz mais sentido injetar uma interface no construtor para desacoplar sua lógica de negócio.

Tá tudo bem usar Facades. Esse post não é uma regra. É só uma lente que eu peguei dos meus estudos e que, de vez em quando, me faz perguntar: “será que aqui vale a pena declarar a dependência?”

Fico curiosa pra saber como vocês lidam com isso. Já sentiu alguma dificuldade prática com Facades para testar, evoluir ou reaproveitar lógica? Ou acham que eliminar Facades do Laravel da camada de negócio é uma sofisticação desnecessária?

Produtividade com Testes e Vue usando VSCode

Meriéli Manzano — Mon, 26 Sep 2022 14:18:02 +0000

Criar testes bem organizados, separados e com uma boa descrição no Jest ou inserir toda estrutura inicial padrão de um componente Vue, pode ser verboso. Mas configurando o VS Code é possível inserir automaticamente toda pré-estrutura com a escrita de apenas uma palavra.

Desenvolvendo com o Visual Studio Code você pode turbinar sua produtividade de uma forma muito simples com Snippets!

Como funciona?

Os snippets salvos no seu VS Code geram códigos pré-definidos ao digitar uma determinada palavra escolhida na sua configuração.

Como criar um snippet

Com o VS Code aberto vá em File -> Preferences -> Configure User Snippets

Na paleta de comandos aberta digite a linguagem para qual deseja exibir o snippet, no caso de testes Jest digite typescript se for sua linguagem utilizada.

Será aberto um arquivo typescript.json com instruções para criar seu snippet.

Cada snippet tem a seguinte estrutura:

"Nome do Snippet": {
        "prefix": // Palavra que chama o snippet,
        "body": [
            // Corpo com o código a ser gerado         
        ],
        "description": // Descrição com detalhes do código
},

Ao escrever o body, em linhas que houver indentação use \t para aplicar a tabulação necessária. Cada \t representa um Tab.

Para indicar as pausas do Tab para digitação de texto pelo código use $1, substituindo o número pela ordem de inserção desejada em cada trecho.

Também é possível indicar o tipo de conteúdo a ser inserido em cada pausa com ${1:conteudo} dando uma ideia do que escrever. E para definir um texto igual a ser usado em várias partes do código use o mesmo número de ID em todas partes que o texto for repetir.

Abaixo montei um snippet completo para Jest usando BDD que você pode aproveitar nos seus códigos ou adaptar como preferir:

O snippet de Vue é para uso com composition Api usando Typescript e Sass scoped, mas você pode adaptar como preferir:

O artigo é para produtividade com Testes e Vue, mas também é possível criar snippets para outras linguagens.

Espero ter ajudado! 😊

DEV Community: Meriéli Manzano

Facades no Laravel entregam velocidade, mas cobram o preço em acoplamento

Produtividade com Testes e Vue usando VSCode

Como funciona?

Como criar um snippet