If you’ve been developing with Laravel for a while, you’ve probably heard the phrase "clean code" tossed around. But what does it actually mean in the context of Laravel development? More importantly, why should you care?
"Clean Code" refers to code that is easy to understand, maintain, and extend. Clean code architecture takes this one step further by providing a structure that makes it easier to keep your codebase clean as your application grows. In this blog, we’ll explore how you can implement clean code architecture in Laravel to make your projects more scalable, maintainable, and enjoyable to work on.
Table of Contents
- What is Clean Code Architecture?
- Why You Should Care About Clean Code
- Key Principles of Clean Code Architecture
- Implementing Clean Code Architecture in Laravel
- Real-World Example: Building a Blog Platform
- Best Practices for Clean Code in Laravel
- Final Thoughts
What is Clean Code Architecture?
Clean code architecture is a way of organizing your application to make it easier to maintain and scale. It’s not tied to any particular framework or language, and it separates your application into layers. Each layer has a specific responsibility and is loosely coupled to the others.
This separation helps you avoid the infamous "spaghetti code" where everything is tangled together. With clean code architecture, your business logic is kept separate from your user interface and data access, allowing you to make changes to one part of the application without breaking the entire system.
Why You Should Care About Clean Code
Writing clean code isn’t just about making your code look nice; it’s about making your life easier in the long run. When your code is clean:
- It’s easier to debug: Clear, well-structured code helps you find and fix bugs faster.
- It’s easier to scale: When your app grows, clean code makes it easier to add new features without breaking existing ones.
- It’s easier to work with others: Whether you’re working with a team or sharing your project with the open-source community, clean code is easier for others to understand.
In a framework like Laravel, which encourages rapid development, it can be tempting to focus on building quickly rather than cleanly. But by following clean code principles, you’ll end up saving time and effort in the long run.
Key Principles of Clean Code Architecture
Before we dive into how to implement clean code architecture in Laravel, let’s go over a few key principles:
- Separation of Concerns: Each layer in your architecture should have a specific responsibility, and you should avoid mixing concerns (e.g., don’t put database logic in your controllers).
- Dependency Inversion: Higher-level modules should not depend on lower-level modules. Instead, both should depend on abstractions (like interfaces).
- Single Responsibility Principle: Every class or function should do one thing and do it well. This makes it easier to test and maintain your code.
Implementing Clean Code Architecture in Laravel
Now, let’s see how you can implement clean code architecture in a Laravel application.
Entities and Use Cases
At the core of clean code architecture are entities and use cases. Entities are the core objects in your system (like a Post
or User
), and use cases define what you can do with those entities (like creating a post or deleting a user).
In Laravel, entities can be represented as Eloquent models, while use cases are typically services that perform specific actions on these models.
For example, let’s create a simple use case for creating a blog post:
// app/Domain/Post/Post.php
class Post {
private $title;
private $content;
public function __construct($title, $content) {
$this->title = $title;
$this->content = $content;
}
// Getter methods and other domain logic
}
And here’s a use case for creating a new post:
// app/Services/Post/CreatePostService.php
class CreatePostService {
private $postRepository;
public function __construct(PostRepositoryInterface $postRepository) {
$this->postRepository = $postRepository;
}
public function execute($data) {
$post = new Post($data['title'], $data['content']);
$this->postRepository->save($post);
}
}
Note on Entities: While it’s tempting to use Eloquent models as entities, this can tie your core application logic directly to the database. To achieve true clean code architecture, consider creating separate value objects for your domain entities. These value objects can mirror the properties of your database but remain independent of the underlying storage layer, allowing for greater flexibility and modularity.
Repositories and Interfaces
In clean code architecture, repositories handle data access, and interfaces define the methods that repositories should implement. This way, your business logic doesn’t depend on the database or ORM you’re using—it depends on the abstraction.
Let’s create an interface for the PostRepository
:
// app/Repositories/PostRepositoryInterface.php
interface PostRepositoryInterface {
public function save(Post $post): void;
public function findById($id): ?Post;
}
And an Eloquent implementation of this repository:
// app/Repositories/EloquentPostRepository.php
class EloquentPostRepository implements PostRepositoryInterface {
public function save(Post $post): void {
// Save post using Eloquent
}
public function findById($id): ?Post {
// Fetch post using Eloquent
}
}
Controllers and Dependency Injection
Your controllers should be thin, meaning they should only handle HTTP requests and delegate the heavy lifting to services. By using dependency injection, you can inject the necessary services into your controllers.
// app/Http/Controllers/PostController.php
class PostController {
private $createPostService;
public function __construct(CreatePostService $createPostService) {
$this->createPostService = $createPostService;
}
public function store(Request $request) {
$this->createPostService->execute($request->all());
return response()->json(['message' => 'Post created!']);
}
}
Services and Business Logic
All your business logic should live in services. This keeps your controllers clean and ensures that your logic can be reused across different parts of your application.
// app/Services/Post/CreatePostService.php
class CreatePostService {
private $postRepository;
public function __construct(PostRepositoryInterface $postRepository) {
$this->postRepository = $postRepository;
}
public function execute($data) {
$post = new Post($data['title'], $data['content']);
$this->postRepository->save($post);
}
}
Real-World Example: Building a Blog Platform
Let’s walk through a real-world example of building a simple blog platform. Here’s how you would structure it using clean code architecture:
-
Entities: Your
Post
andUser
models. -
Repositories: Interfaces like
PostRepositoryInterface
andUserRepositoryInterface
, and implementations likeEloquentPostRepository
. -
Services:
CreatePostService
,DeletePostService
, etc. - Controllers: Thin controllers that delegate work to services.
This separation ensures that your code remains modular and easy to test. For example, if you decide to switch from Eloquent to another ORM, you’d only need to update the repository implementation, not your entire application.
Best Practices for Clean Code in Laravel
- Keep Controllers Thin: Let your services handle the business logic.
- Use Dependency Injection: This makes your code easier to test and maintain.
- Write Unit Tests: Clean code architecture makes it easier to write tests, so make sure you take advantage of that.
- Separate Concerns: Keep business logic, data access, and presentation code separate.
Final Thoughts
Clean code architecture isn’t just for large enterprise applications—it’s a mindset that helps you keep your codebase clean and organized, even for small to medium-sized projects. By separating concerns, using dependency injection, and following the single responsibility principle, you’ll find your Laravel applications easier to maintain, test, and scale.
Start small. Try refactoring one part of your Laravel app to follow clean code architecture, and you’ll quickly see the benefits.
Happy coding!
Top comments (3)
Well done, with an exception of entites. They should not be Eloquent entities. You're putting database objects right in the center of your app, while they should be on its outside part. Create value objects even if they are the same properties as columns in your database.
Thank you for your feedback! You’re absolutely right; placing Eloquent models as entities can blur the lines between core business logic and infrastructure. Using value objects for core domain models, separate from database entities, is indeed a cleaner approach.
This is a good explanation to a somewhat "business" architecture, but the text isn't really about clean architecture.
When you highlight the key points, while they're important concepts to clean arch, they aren't the key concepts. The architecture has 2 core ideas independence of the domain logic, and the screaming architecture concept.
While, yes, separation of the concerns is important, clean arch is more about decouple your domain logic from the rest of the application, like in the hexagonal arch, and show to who see your project that that project isn't a laravel project, but a clinical schedule system.
If the first thing a programmer sees when it opens your project is the laravel folder structure, then you failed to apply clean arch, because the system itself doesn't scream its purpouse. Ideally (besides not being the most pragmatic approuch) your laravel project, should be a folder or a separated project from the main one that implements the concepts of the clean arch.
The layers aren't entities, repositories, services, and controllers (which is much closer to onion arch), they are entities, use cases, interface adapters, and frameworks and drivers.
The book doesn't specify that you should implement the persistance adapters via the repository pattern (most of the examples use the gateway pattern for example), neither that you should use service (though they are pretty much the same as the interactors used in the book).
Controllers aren't much delegates, they are more adapters in this style, you can see then as the http adapters to the application.
The business logic doesn't live in the services. they could have some business logic related with the execution of a use case, but putting all the business logic there you're doing a service layer, and thats not what we want to do, because the business logic lives in your entities, the use cases only coordinate the entities, and apply business logic related with that coordination, but it should not ensure the most important business logics, this is the job of the entities.
Putting all the business logic on the service layer is just bad oop, and makes the code lack cohesion, because now the policies that ensures the data integrity aren't with the data itself, but in a separated place, which not grant any security that the data will be manipulated in the correct way.