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.
See what three files turn into.
Three definition files in, a complete bounded context out. Browse the generated code.
# Database Schema — Sales Bounded Context
# This file defines the persistent storage structure.
schema:
domain: ECommerce
boundedContext: Sales
tables:
order:
columns:
id:
type: integer
primary: true
autoIncrement: true
public_id:
type: uuid7
unique: true
customer_email:
type: string
length: 255
status:
type: string
length: 32
default: "draft"
total_amount:
type: integer
currency:
type: string
length: 3
default: "EUR"
created_at:
type: datetime
updated_at:
type: datetime
nullable: true
order_item:
columns:
id:
type: integer
primary: true
autoIncrement: true
order_id:
type: integer
foreignKey:
table: order
column: id
onDelete: cascade
product_name:
type: string
length: 255
sku:
type: string
length: 64
quantity:
type: integer
unit_price:
type: integer
line_total:
type: integer
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 WaitlistStructure costs less than chaos.
Try Jardis 7 Days Free
Point Jardis at your real domain. Discovery, structure, and your first platform build.
Join WaitlistThe complete DDD architecture with all classes and contracts. Your team ships features, not infrastructure.
Join WaitlistThe complete business logic with handlers, validation, and pipelines. What used to be a sprint is now a build.
Join WaitlistMore than 20 Platform Builds per month?
Let's talkBe there when Jardis launches.
Sign up. You'll get access as soon as we go live. Including a free trial.
Curious how Jardis works?
Discover JardisFrequently 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.