Troquei Services por Actions no Laravel

No Laravel, é comum usar a classe Service para organizar regras de negócio, mas já me deparei com um problema: conforme o projeto cresce, esses services viram verdadeiros Frankensteins, cheios de métodos e difíceis de manter.

Passei por isso em um projeto onde desenvolvi uma API com vários endpoints dentro de um mesmo módulo. No início, manter tudo dentro de um único service parecia prático, mas conforme a lógica crescia, começou a ficar bem complicado dar manutenção. Eu precisava navegar por um arquivo enorme para encontrar o que precisava.

Pesquisando alternativas, encontrei a abordagem de Actions, que já estava sendo utilizada nos starter kits do Laravel. Como eu já costumava organizar os métodos dos services por ações, a adaptação foi tranquila: separei cada ação em uma classe própria e movi os métodos auxiliares para helpers ou outras Actions. No fim, o código ficou mais modular, mais legível e muito mais fácil de testar.

Essa abordagem lembra bastante os Use Cases da Clean Architecture e ajuda a aplicar SOLID, principalmente:
✅ SRP: Cada classe tem apenas uma responsabilidade.
✅ OCP: Para novas ações, basta criar uma nova Action sem alterar o código existente.
✅ DIP: As Actions podem depender de interfaces, facilitando testes e manutenção.

O único ponto negativo é que agora tenho mais arquivos para lidar, e em alguns momentos é chato ter vários deles abertos ao mesmo tempo. Mas, no geral, a organização e a escalabilidade compensam bastante.

Depois dessa experiência, passei a adotar Actions nos novos projetos e não me vejo mais voltando para Services tradicionais. E você, já usou Actions no Laravel? se você utiliza outra a bordagem compartilha aqui? 🚀