Clean ArchitectureLaravelUncle BobFrameworkMaintainability

Using Clean Architecture in Laravel Projects: a practical experiment

When we talk about Clean Architecture, we immediately think of Uncle Bob’s (Robert C. Martin) concentric circle diagram that separates systems into independent layers, isolating business rules from external dependencies. Many developers associate this concept with languages like Java or C#, but is it possible to apply these principles in a Laravel project, even though the framework offers so many built-in “shortcuts”?

Spoiler: yes, it is. And better yet — it’s worth it.

Laravel doesn’t have to be a limiter

Laravel is undoubtedly a powerful framework. It provides convenient solutions for migrations, validation, controllers, services, events, jobs, and countless other features that accelerate development. But sometimes this makes us feel “locked in” to doing things the Laravel way, without questioning if we’re truly respecting separation of concerns.

Clean Architecture suggests quite the opposite: that our business rules should not depend on frameworks, databases, or any external technology. The core of your system should stand on its own. This gives you the freedom to evolve, swap implementations, and test with far less friction.

My experiment with Laravel + Clean Architecture

Last year, I took Rodrigo Branas’ Clean Code and Clean Architecture course, which I highly recommend. To solidify what I learned, I decided to apply everything in a test Laravel project. The result is this repository:

👉 https://github.com/ranierif/laravel-clean-architecture

The goal wasn’t to build something production-ready, but to explore how to decouple the domain from Laravel. In it you’ll find:

• Use Cases, purely responsible for orchestrating business rules, without any framework dependency.
• Entities representing the heart of the domain, completely independent from Eloquent or any ORM.
• Interfaces (Ports) for persistence, so you could swap Eloquent for something else with zero impact.
• Implementations (Adapters) using Eloquent, injected into the use cases.
• Controllers acting only as orchestrators, delegating real work to the domain.

A key point was realizing that we don’t need to ignore Laravel, we just shouldn’t couple our business rules to it. It’s great to use Eloquent, jobs, events — as long as your domain knows nothing about them.

Frameworks come and go, business rules stay

Frameworks change, databases evolve, queue drivers switch. But your business rules — the logic that actually solves your client’s problem — must endure all that. Clean Architecture helps us ensure they do.

Don’t fall into the trap of thinking “Laravel already does it this way, so I’ll just follow along.” Question it. See if it makes sense for your project. For simpler applications, the framework defaults might be enough. But for projects with complex domains or businesses that will evolve a lot, Clean Architecture can save you hours (or days) of refactoring later.

Conclusion

This experiment strongly reinforced for me what Uncle Bob always says: “Frameworks are details. Your system should not depend on them to exist.”

If you want to dive into the project or discuss architecture, feel free to ping me on LinkedIn or open an issue in the repo. Who knows, maybe we’ll evolve this project together!