Laravel makes it genuinely easy to write bad architecture fast - Eloquent models with business logic scattered directly in controllers, fat models doing everything from validation to external API calls, and a codebase that works fine at first and becomes genuinely painful to change six months in. None of this is Laravel’s fault specifically; it’s what happens when a framework this convenient doesn’t come with enforced structure, and a team doesn’t deliberately impose their own.
What “clean architecture” actually means here, without the dogma
The core idea, stripped of the more academic framing it sometimes gets wrapped in: your actual business logic - the rules that make your application what it is - shouldn’t know or care that it’s running inside Laravel specifically. It shouldn’t be tangled up with Eloquent queries, HTTP request objects, or framework-specific conventions. If you could theoretically swap Laravel for a different framework and your core business rules would survive mostly unchanged, you’ve achieved the actual goal. If your business logic is scattered through controllers and model methods that only make sense in the context of Laravel’s specific conventions, it hasn’t.
What this looks like in practice, concretely
- Thin controllers. A controller’s job is translating an HTTP request into a call to your actual business logic, and translating the result back into an HTTP response - nothing more. If a controller method is more than a handful of lines, business logic has probably leaked into it.
- Service classes or action classes for business logic, independent of Eloquent and HTTP concerns, that contain the actual rules of your application - “process this order,” “calculate this user’s eligibility” - as plain PHP that could theoretically be tested and reused without spinning up the full framework.
- Repository or data-access abstraction between your business logic and Eloquent specifically, so business logic asks for “the active orders for this customer” through an interface, not by directly chaining Eloquent query builder calls - this is what actually lets you test business logic without hitting a real database, and what makes a future data-layer change (a different ORM, a different data source for part of the system) a contained change rather than a rewrite.
- Framework-agnostic validation and business rules, separate from Laravel’s Form Request validation, which is genuinely great for input validation but shouldn’t be where actual business rule enforcement lives - a business rule like “this discount can’t be applied to already-discounted items” belongs in your service layer, not scattered across form request classes.
Where we push back on over-applying this
Full hexagonal or onion architecture, with strict layer boundaries enforced everywhere, is genuinely overkill for a small CRUD application or an early-stage MVP where the business logic is simple and the team is small - the ceremony costs more than it returns at that scale. We apply this discipline in proportion to actual complexity: a payments module handling real business rules gets the full treatment; a simple settings page doesn’t need a repository interface and a dedicated service class for what’s fundamentally a straightforward update.
Why this matters more as a codebase ages
The cost of tangled business logic isn’t visible on day one - it’s visible eighteen months in, when a new developer needs three days to understand what a single controller method actually does because the business logic is inseparable from Eloquent calls and HTTP-specific code. Clean architecture, applied where it actually matters, is what keeps that onboarding time and change cost from compounding as a Laravel application grows.
We build Laravel applications with this discipline from the start on any project with real business complexity. If your Laravel codebase has grown organically and changes are getting slower and riskier, get in touch - we’ll look at whether an architectural cleanup or a full rewrite is actually the right call.