Repository Pattern no Laravel: Uma Análise Crítica

Luciano Charles de Souza — Fri, 25 Jul 2025 16:30:38 +0000

No ecossistema Laravel, uma das discussões mais recorrentes e controversas envolve o uso do Repository Pattern com o Eloquent ORM.
Frequentemente, influenciados por tutoriais e cursos online, vemos desenvolvedores implementando este padrão como uma tentativa de alcançar uma arquitetura mais limpa e testável.

Porém, será que essa abordagem realmente cumpre seu propósito dentro do contexto do Laravel, ou apenas aplica mais complexidade desnecessária?

Neste artigo, vamos fazer uma análise crítica sobre o uso do Repository Pattern em projetos Laravel, discutindo:

Suas motivações reais
Os benefícios e armadilhas comuns
A relação entre Repository Pattern e Domain-Driven Design (DDD)
Quando essa abordagem faz (ou não faz) sentido

Qual é a motivação para usar Repository Pattern no Laravel?

Muitos desenvolvedores implementam Repositories com o objetivo de:

Desacoplar a lógica de acesso a dados do restante da aplicação
Facilitar a troca do ORM (por exemplo, substituir o Eloquent por outro mecanismo)
Tornar a aplicação mais testável, principalmente utilizando mocks nos testes

Porém, existe um problema: a maioria dessas implementações acaba sendo apenas um wrapper em torno do próprio Eloquent.

💡 Exemplo clássico de Repository simplista:

class EloquentUserRepository implements UserRepositoryInterface 
{
    public function all() {
        return User::all();
    }

    public function find($id) {
        return User::find($id);
    }
}

Essa camada, muitas vezes, não oferece nenhum valor real, já que apenas repassa os métodos do Eloquent sem adicionar regras de negócio ou abstrações relevantes.

O que é realmente um Repository de verdade?

Segundo o DDD de Eric Evans, um Repository é:

"Um mecanismo para encapsular o acesso a coleções de objetos de uma dada entidade de domínio, fornecendo uma interface que simula uma coleção em memória."

Ou seja, um Repository não deveria conhecer a tecnologia usada para acessar os dados (Eloquent, SQL puro, API externa, etc). Ele deve funcionar como um intermediário entre o domínio e as fontes de dados.

Além disso, um Repository maduro não retorna Eloquent Models diretamente. Ele retorna:

Entidades do domínio (quando aplicável)
Objetos de transferência de dados (DTOs)
Coleções de objetos de negócio

Mas o Laravel já é um Active Record… e isso importa!

O Laravel utiliza o padrão Active Record com o Eloquent, o que torna cada modelo responsável tanto por sua lógica de negócio quanto por seu acesso ao banco de dados.

Por isso, tentar simular um repositório "puro" dentro do Laravel exige muito cuidado, pois:

O Eloquent já mistura persistência com lógica de negócio
Muitos desenvolvedores acabam apenas replicando métodos existentes do Eloquent
O acoplamento com Eloquent continua existindo, mas agora em dois lugares: no Repository e no Model

⚠️ Ou seja: criar um Repository que só chama User::find($id) não está tornando seu código mais limpo nem mais testável.

Um Repository útil dentro do Laravel

Se mesmo assim você quiser utilizar Repository Pattern, procure seguir esta prática:

✅ Quando usar Repository faz sentido no Laravel

Você está adotando DDD e precisa separar os conceitos de domínio do acesso a dados, então voce deixaria o Eloquent de lado e, passaria a usar o padrão de Data Mapper, como o que o Doctrine oferta.

❌ Quando não usar

Apenas por "boas práticas genéricas"
Para fazer pass-throughs simples do tipo return User::all()
Para fingir que sua aplicação é mais abstrata do que realmente é

Considerações finais

O Repository Pattern pode ser uma ferramenta poderosa quando utilizada com propósito e conhecimento. Mas, no contexto do Laravel, é importante considerar:

O Eloquent já fornece uma API riquíssima, que muitas vezes dispensa a criação de Repositories
Adicionar uma camada extra sem lógica de negócio só traz complexidade
Usar Repository apenas para testes unitários pode ser um sinal de que o design precisa ser revisto

✅ Em vez de usar Repository Pattern por padrão, prefira:

Usar Service Layer com Eloquent Direto
Criar Query Objects Pattern para Queries Complexas
Criar Eloquent Scopes para Queries Reutilizáveis

Conclusão

Se você estiver usando Repositories apenas para "ficar mais limpo" ou "porque ouvi dizer que é melhor", talvez seja hora de repensar. O Laravel já é poderoso o suficiente para permitir código limpo e organizado(se voce não bagunçar tudo) sem a necessidade de um Repository Pattern genérico.

E você, tem usado Repository Pattern nos seus projetos Laravel? Tem alguma abordagem que resolveu esse impasse para você? Compartilha nos comentários!

DEV Community: Luciano Charles de Souza