I recently finished Clean Architecture by Robert C. Martin, and it was a reminder that good architecture is about clear boundaries and long-term thinking — not about which framework you pick.
The core idea
The book’s central argument is simple: business rules should not depend on anything external. Not on the database, not on the HTTP layer, not on Laravel, not on React. If your domain logic can be tested without booting the framework, you are probably on the right track.
Martin organizes this around what he calls the Dependency Rule: source code dependencies must point inward, toward higher-level policies. The UI, the database, the web framework — these are all details. They can be swapped out without touching the core.
What surprised me
I had heard “separate your business logic” a thousand times. What the book adds is a concrete vocabulary and a model for why it matters:
- Entities: enterprise-wide business rules. They change only when fundamental business requirements change.
- Use Cases: application-specific rules. They orchestrate entities and define what the system does.
- Interface Adapters: convert data between use cases and the outside world (controllers, presenters, gateways).
- Frameworks & Drivers: the outermost layer — database, web, devices. Pure glue.
The key insight is that use cases drive the architecture, not the framework. Once I internalized this, I started looking at my Laravel controllers differently. They should be thin adapters, not the place where decisions live.
How I’m applying it at work
At LIVE!, we maintain an event registration platform with a mobile app. The codebase has evolved over years, so there are parts where controllers do too much, and parts where the separation is clean.
Reading this book gave me better language to talk about these trade-offs in code reviews: this is a use case concern, this belongs in the adapter layer, this dependency is pointing in the wrong direction.
It also reinforced a pattern we already use: keeping the Laravel framework out of the core domain classes as much as possible, so that unit tests run fast and don’t need to boot the framework.
Should you read it?
If you are building systems that need to evolve over years — yes, absolutely. The book is not framework-specific. The principles apply whether you are writing PHP, Go, or anything else.
It won’t tell you how to structure your folders, but it will tell you why the structure matters. That understanding is more durable than any convention.
“The goal of software architecture is to minimize the human resources required to build and maintain the required system.” — Robert C. Martin