Implementing the Service Layer in Laravel for Maintainable Code

Previously in this course, we discussed architecting for maintainability, where we identified the dangers of controller bloat and began extracting logic into custom classes. In this lesson, we take that architectural shift further by formalizing our approach to business logic through the service layer.

The Problem: When Controllers Do Too Much

In a typical Laravel application, developers often start by placing business logic directly inside controller methods. While convenient for small prototypes, this approach leads to "fat controllers" that are difficult to unit test and impossible to reuse.

When you need to trigger the same "Project Creation" logic from a web form, an API endpoint, and an Artisan command, a controller-bound implementation forces you to duplicate code. A service layer solves this by acting as the mediator between your HTTP layer (controllers) and your data layer (models/repositories).

What is a Service Layer?

A service layer is a set of classes that hold your application's "business rules." These classes are agnostic of the request cycle; they don't know about $request, session data, or redirects. They simply receive data, perform an action, and return a result or throw an exception.

By moving business logic into these classes, you ensure your controllers remain "thin," responsible only for:

1. Validating the incoming request.
2. Invoking the appropriate service.
3. Returning an appropriate HTTP response.

Worked Example: Creating a Project Service

Let's evolve our project board by creating a ProjectService. Suppose our logic requires creating a project and immediately assigning it to the authenticated user.

First, create the directory structure: app/Services. Now, define the service:

PHP
namespace App\Services;

use App\Models\Project;
use App\Models\User;

class ProjectService
{
    public function createProject(array $data, User $user): Project
    {
        #6A9955">// Encapsulate business logic: project creation + ownership assignment
        return $user->projects()->create([
            'name' => $data['name'],
            'description' => $data['description'],
            'is_active' => true,
        ]);
    }
}

Next, inject this service into your ProjectController. Because Laravel’s service container is powerful, we can type-hint the service in the controller constructor or directly in the method.

PHP
namespace App\Http\Controllers;

use App\Services\ProjectService;
use Illuminate\Http\Request;

class ProjectController extends Controller
{
    protected $projectService;

    public function __construct(ProjectService $projectService)
    {
        $this->projectService = $projectService;
    }

    public function store(Request $request)
    {
        $validated = $request->validate([
            'name' => 'required|string|max:255',
            'description' => 'nullable|string',
        ]);

        $project = $this->projectService->createProject($validated, auth()->user());

        return response()->json($project, 201);
    }
}

By doing this, the controller no longer cares how a project is created—it only cares that the ProjectService fulfills the contract. If you later decide to add logging, fire events, or notify team members upon project creation, you only update the service, and all entry points (API, Web, CLI) benefit automatically.

Hands-on Exercise

1. Create a TaskService class in app/Services.
2. Add a createTask method that accepts an array of data and a Project model instance.
3. Refactor your TaskController@store method to inject TaskService and use it to handle the task creation logic instead of calling Task::create() directly.
4. Verify that the task is still correctly associated with the project.

Common Pitfalls

• Over-Engineering: Do not create a service class for every single model. If your logic is just a simple Model::create($request->all()), keep it in the controller. Use services when the logic involves multiple steps, external API calls, or complex domain rules.
• Service-to-Service Dependency: While allowed, avoid deeply nested service dependencies. If Service A calls Service B, which calls Service C, you might be creating a "circular dependency" or making the code hard to debug.
• Ignoring the Container: Always inject services via the constructor or method injection. Manually instantiating services with new ProjectService() makes your code harder to mock during testing, which we will cover later in this course.

Recap

The service layer is a design pattern that keeps your application maintainable as it grows. By separating business logic from HTTP concerns, you create a cleaner codebase that is easier to test and reuse. Remember: controllers handle the request/response, and services handle the "work."

Up next, we will look at the Repository Pattern Fundamentals to further decouple our services from the database layer.