DDD with Laravel. Without fighting Laravel.
Laravel is built for HTTP, routing, and infrastructure. Not for Domain-Driven Design. Jardis adds the architecture layer Laravel does not ship with: Bounded Contexts, CQRS, Domain Events, and a clear separation of business logic.
Why DDD with Laravel alone does not work.
Laravel is an excellent framework. But its conventions actively work against DDD principles.
Eloquent vs. Domain Entities
Active Record mixes persistence and business logic in a single class. In DDD, that is an anti-pattern. Domain Entities belong in their own layer, separated from Eloquent and the database.
Business logic scattered everywhere
Controllers, FormRequests, Observers, Jobs, Event Listeners. Laravel offers many places for logic but no clear home for domain rules. The result: business logic spreads across dozens of files. New developers have no idea where a rule lives.
God Models instead of Bounded Contexts
A User model with 40 methods, 15 relationships, and logic for billing, notifications, and permissions. Without explicit domain boundaries, Eloquent models grow into monoliths. Any change to one model can trigger side effects in completely unrelated features.
How Jardis brings DDD to Laravel projects.
Jardis does not replace Laravel. Laravel stays responsible for HTTP, routing, auth, and queues. Jardis takes over the domain layer that Laravel does not ship.
DDD with Laravel as a standalone architecture layer
The builder generates Bounded Contexts as standalone PHP packages that live alongside Laravel's structure. Domain Entities, Value Objects, Aggregates: cleanly separated from Eloquent. Your domain logic has a home that is not dictated by Laravel conventions.
Commands, Queries, and Domain Events instead of fat controllers
Jardis generates the complete CQRS infrastructure in PHP: Commands, Command Handlers, Queries, Query Handlers, and Domain Events. Business logic moves from controllers into explicit commands. Laravel controllers become thin and only call into the domain layer.
Alongside Laravel, not against it
The generated code uses Laravel's service container, queue system, and event dispatcher. No parallel infrastructure, no framework switch. Your team keeps working with Laravel, but domain logic lives in a clean, generated architecture.
Why Laravel teams use Jardis for DDD.
Not because Laravel is wrong. But because Laravel was built for HTTP, not for domain logic.
Bounded Contexts instead of God Models
Each domain becomes a standalone package with its own folder structure. User, Billing, Notifications: physically separated instead of crammed into one Eloquent model.
Domain architecture from day one
No weeks of debating folder structures. The builder generates the DDD infrastructure, your Laravel team writes the business rules that differentiate your product from the start.
Domain logic independent of Laravel
The generated domain code has no Laravel dependencies. If you ever switch frameworks or extract services, the domain layer stays portable.
Ready to bring DDD into your Laravel project?
Join the WaitlistFrequently Asked Questions
Answers to the most important questions about Jardis and Laravel in a DDD context.
No. Laravel stays responsible for HTTP, routing, auth, queues, and everything else it was built for. Jardis generates only the domain layer: PHP Entities, Aggregates, Commands, Queries, Domain Events, and the Repository Pipeline. These live as standalone packages next to Laravel's app/ directory.