The first time I opened a Laravel project, I found a single “create user” operation spread across seven files: a Controller, a Request DTO, a UseCase, a Domain Entity, a Repository Interface, an Eloquent Repository, and a two-way Mapper. The only business rule inside it was that the email had to be unique.

This was Clean Architecture applied wrong — but the blame is not on Clean Architecture. The blame is on never asking which project needs which discipline.

The two approaches, briefly

Layered architecture is the familiar one: Controller → Service → Repository → database. Dependencies flow top to bottom, with the framework sitting at the very bottom. Laravel itself is already this — Eloquent is an active record, controllers are bound to HTTP, everything is embedded in the framework.

Clean Architecture (and its relatives, hexagonal and onion) reverses the direction of dependency: a framework-unaware domain sits at the center, and dependencies point inward. The database, HTTP, the framework — all of them live in the outermost ring, as details. The domain does not know Laravel exists.

The difference is not philosophical, it is very concrete: in layered architecture the domain depends on Eloquent; in Clean, Eloquent depends on the domain.

What Clean Architecture buys you

It is not free, but it gives you real things:

  • Framework-independent tests. Domain rules run with pure unit tests, without a database. Fast and not brittle.
  • A domain that outlives the framework. Business rules live independently of Laravel versions. A ten-year-old domain can survive three major framework upgrades.
  • Multiple delivery mechanisms. Calling the same domain over an HTTP API, a CLI command, and a queue worker becomes natural.

What you pay in return is just as concrete: mapping at every layer boundary, more files, more indirection. Seven files for a one-line rule — the scene at the top of this piece.

For most Laravel projects, layered is enough

Let me be blunt: most web applications are CRUD at their core. Validate the data, save it, read it, show it. In an application like that, fighting against Eloquent for the sake of “clean code” costs more than the value it wins.

Treat Laravel not as a detail but as a deliberately chosen foundation. Controller + Form Request + Eloquent model + a thin service class — that is the right weight for the vast majority of projects. Embracing the framework is not a concession, it is a decision; just like boring architecture.

A seven-layer CRUD, on the other hand, is speculative generality at architectural scale: paying a tax today for a complexity that does not exist today.

When Clean Architecture pays off

The discipline delivers a real return when domain complexity is high. Take it seriously if these signals are present:

  • The business rules go far beyond “save/read”: multi-step calculations, state machines, sector regulations.
  • These rules are expected to outlive the framework.
  • The same domain is fed by more than one interface — API, CLI, message queue, dashboard.
  • Rule changes are frequent and risky; being able to test without touching the database gives a real speed gain.

Insurance premium pricing, accounting, logistics optimization — in these domains the indirection of Clean Architecture pays for itself. In a blog or a standard admin panel, it does not.

It is not all or nothing

The point most often missed: this is not a binary choice. Both can live together in the same codebase.

Isolate the module where the domain is genuinely complex — say, pricing — in the Clean style: a pure domain, a repository separated by an interface, framework-independent tests. Leave the rest of the CRUD modules flat: controller, Eloquent, thin service. The boundaries that a modular monolith provides make this natural — each module carries its own weight.

Architecture is not a rule applied uniformly across a project; it is a budget tuned to where the complexity concentrates.

Clean Architecture is not a badge, it is a tool. If your domain lives the problem it solves, it is priceless; if it does not, it is just a ceremony that splits a one-line rule into seven files.

The domain chooses the architecture — not fashion.