Skip to main content
SC

Best practices for Laravel 11 service layer pattern?

Sarah Chen Laravel & PHP 130 views
I am refactoring a large Laravel 11 application and want to properly implement a service layer pattern. Currently my controllers have become fat with business logic mixed in. For example, my store method has 50+ lines of business logic before the redirect. I know this should be extracted into a service class. My questions: 1. Should services be injected via constructor or method injection? 2. How do you handle services that need to call other services? 3. Any recommendations for organizing services in a domain-driven structure? Would love to hear how others structure their Laravel apps at scale.

2 Replies

Best Answer
EA
Engr Mejba Ahmed 5 days ago
Great question Sarah! Here is the pattern I use across projects at Ramlit Limited and ElectronicFirst.com: 1. Constructor injection for services the controller always needs. 2. Method injection for optional or context-specific dependencies. 3. Services organized by domain: App\Services\Blog\PostService, App\Services\Shop\OrderService. For services calling other services, I follow a simple rule: if Service A needs Service B, inject it via constructor. But if the dependency chain goes deeper than 2 levels, it is usually a sign you need to rethink the domain boundaries. Also, keep each service focused. A service should not be a dumping ground for all business logic. One service per aggregate root works well in practice.
MR
Marcus Rivera 4 days ago
I would add: consider the Actions pattern for single-purpose operations. A service class can orchestrate multiple actions. For example, a CreateOrderAction handles just that one responsibility. This keeps things testable and reusable. I have found Actions + Services together work beautifully in Laravel for medium to large projects.

Post a Reply