Boas práticas com Laravel em projetos grandes

Trabalhar com Laravel em projetos pequenos é simples. Mas conforme o sistema cresce — mais desenvolvedores, mais regras de negócio, mais integrações — a estrutura padrão começa a dar sinais de que precisa evoluir. Neste artigo compartilho as práticas que adotei ao longo de anos trabalhando em projetos Laravel de médio e grande porte.

1. Separe a lógica de negócio dos Controllers

Um dos erros mais comuns em projetos Laravel é colocar toda a lógica no controller. Controllers devem ser finos: receber a requisição, delegar para um serviço e retornar a resposta.

A Service Layer resolve isso. Crie uma pasta app/Services e mova toda a lógica de negócio para lá:

// app/Services/UserService.php
class UserService
{
    public function __construct(
        private UserRepository $users,
        private MailService $mail
    ) {}

    public function register(array $data): User
    {
        $user = $this->users->create($data);
        $this->mail->sendWelcome($user);
        return $user;
    }
}

O controller fica limpo e testável:

// app/Http/Controllers/UserController.php
public function store(StoreUserRequest $request): JsonResponse
{
    $user = $this->userService->register($request->validated());
    return response()->json($user, 201);
}

2. Use Form Requests para toda validação

Validações inline no controller poluem o código e são difíceis de reusar. Form Requests encapsulam as regras de validação e autorização em uma classe dedicada.

php artisan make:request StoreUserRequest

Além das regras de validação, o método authorize() permite controlar quem pode fazer a requisição — evitando verificações espalhadas pelos controllers.

3. Repositories para abstrair o banco de dados

O padrão Repository cria uma camada entre a lógica de negócio e a persistência dos dados. Isso facilita testes (você pode mockar o repository) e permite trocar o mecanismo de persistência sem alterar os serviços.

Não use Repository em todo projeto. Em aplicações simples, o Eloquent direto na Service Layer é mais produtivo. Adote Repositories quando a complexidade justificar.

4. Eventos e Listeners para desacoplar efeitos colaterais

Toda vez que você se pega escrevendo código como "quando o usuário se cadastrar, enviar e-mail, criar log, notificar Slack...", está na hora de usar Events e Listeners. O sistema de eventos do Laravel permite que cada responsabilidade fique em sua própria classe, sem acoplar ao fluxo principal.

5. Organize por domínio, não por tipo de arquivo

A estrutura padrão do Laravel organiza por tipo: Controllers, Models, Jobs. Em projetos grandes, considere agrupar por domínio de negócio:

app/
  Billing/
    Controllers/
    Services/
    Models/
    Events/
  Auth/
    Controllers/
    Services/
  Catalog/
    ...

Isso torna o código mais navegável e facilita a separação de responsabilidades entre times.

Conclusão

Não existe bala de prata. Aplique estas práticas progressivamente conforme a complexidade crescer. O objetivo é manter o código legível, testável e fácil de evoluir — não adicionar camadas por adicionar.

---

Tem dúvidas ou sugestões? Me chame no WhatsApp ou no LinkedIn.