Clean Architecture and DDD in Real Laravel Projects

Clean Architecture and Domain-Driven Design are often discussed abstractly. Here is how we apply them in real Laravel projects — pragmatically, without ceremony.

Keep the domain at the center

Business rules should not depend on the framework. Put the core logic — the rules that would be true even without a web app — in plain PHP services and value objects. Controllers, Eloquent, and jobs orbit around that core; they never contain business rules.

Thin controllers, rich services

A controller validates input, calls a service, and returns a response. The service holds the use case. This keeps controllers trivial and makes the real logic testable without HTTP.

Model the domain language

Name things the way the business names them. A clinic has "visits" and "co-pays", not "records" and "amounts". When code speaks the domain language, misunderstandings shrink and onboarding speeds up.

Boundaries via interfaces

External systems — payments, messaging, storage — sit behind interfaces. The domain depends on the interface, not the vendor. This is what makes swapping a provider safe.

Test the rules, not the framework

Unit-test the domain services directly. Feature-test the HTTP layer. You do not need to test that Laravel routes work — you need to test that your rules are correct.

Don't over-engineer

DDD is a toolbox, not a religion. A simple CRUD screen does not need aggregates and repositories. Apply the heavy patterns only where the domain is genuinely complex.

At BarmajTek we build every system this way — clean, documented, and maintainable for years. Learn about our approach or start a project.