DDD mit Laravel. Ohne gegen Laravel zu kämpfen.
Laravel ist gebaut für HTTP, Routing und Infrastruktur. Nicht für Domain-Driven Design. Jardis ergänzt Laravel um die Architektur-Schicht, die es nicht mitbringt: Bounded Contexts, CQRS, Domain Events und eine klare Trennung von Business-Logik.
Warum DDD mit Laravel allein nicht funktioniert.
Laravel ist ein hervorragendes Framework. Aber seine Konventionen arbeiten aktiv gegen DDD-Prinzipien.
Eloquent vs. Domain Entities
Active Record vermischt Persistenz und Business-Logik in einer Klasse. In DDD ist das ein Anti-Pattern. Domain Entities gehören in eine eigene Schicht, getrennt von Eloquent und der Datenbank.
Business-Logik überall verteilt
Controller, FormRequests, Observers, Jobs, Event Listeners. Laravel bietet viele Orte für Logik, aber keinen klaren Ort für Domain-Regeln. Das Ergebnis: Geschäftslogik verstreut sich über Dutzende Dateien. Neue Entwickler wissen nicht, wo eine Regel lebt.
God Models statt Bounded Contexts
Ein User-Model mit 40 Methoden, 15 Relationships und Logik für Billing, Notifications und Permissions. Ohne explizite Domain-Grenzen wachsen Eloquent Models zu Monolithen. Jede Änderung an einem Model kann Seiteneffekte in völlig anderen Features auslösen.
Wie Jardis DDD mit Laravel verbindet.
Jardis ersetzt Laravel nicht. Laravel bleibt für HTTP, Routing, Auth und Queues zuständig. Jardis übernimmt die Domain-Schicht, die Laravel nicht mitliefert.
DDD mit Laravel als eigenständige Architektur-Schicht
Der Builder generiert Bounded Contexts als eigenständige PHP-Packages, die neben Laravels Struktur leben. Domain Entities, Value Objects, Aggregates: sauber getrennt von Eloquent. Deine Domain-Logik hat ein Zuhause, das nicht von Laravels Konventionen diktiert wird.
Commands, Queries und Domain Events statt Fat Controllers
Jardis generiert die komplette CQRS-Infrastruktur in PHP: Commands, Command Handler, Queries, Query Handler und Domain Events. Business-Logik wandert aus Controllern in explizite Commands. Laravel-Controller werden dünn und rufen nur noch die Domain-Schicht auf.
Direkt neben Laravel, nicht dagegen
Der generierte Code nutzt Laravels Service Container, Queue-System und Event-Dispatcher. Keine parallele Infrastruktur, kein Framework-Wechsel. Dein Team arbeitet weiterhin mit Laravel, aber die Domain-Logik lebt in einer sauberen, generierten Architektur.
Sieh selbst, was aus drei Dateien entsteht.
Drei Definitionsdateien rein, ein kompletter Bounded Context raus. Klick dich durch den generierten 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
Warum Laravel-Teams Jardis für DDD einsetzen.
Nicht weil Laravel falsch ist. Sondern weil Laravel für HTTP gebaut wurde, nicht für Domain Logic.
Bounded Contexts statt God Models
Jede Domain wird ein eigenständiges Package mit eigener Ordnerstruktur. User, Billing, Notifications: physisch getrennt statt in einem Eloquent Model zusammengewürfelt.
Domain-Architektur ab Tag eins
Kein wochenlanges Diskutieren über Ordnerstrukturen. Der Builder generiert die DDD-Infrastruktur, dein Laravel-Team schreibt direkt die Business-Regeln, die euer Produkt ausmachen.
Domain-Logik unabhängig von Laravel
Der generierte Domain-Code hat keine Laravel-Abhängigkeiten. Falls ihr jemals das Framework wechselt oder Services extrahiert, bleibt die Domain-Schicht portabel.
Bereit, DDD in euer Laravel-Projekt zu bringen?
Auf die WaitlistStruktur kostet weniger als Chaos.
Teste Jardis 7 Tage kostenlos
Lass Jardis an deiner echten Domäne los. Discovery, Struktur und dein erster Platform Build.
Join WaitlistDie komplette DDD-Architektur mit allen Klassen und Contracts. Dein Team schreibt Features, nicht Infrastruktur.
Join WaitlistDie komplette Business-Logik mit Handlern, Validierung und Pipelines. Was früher ein Sprint war, ist jetzt ein Build.
Join WaitlistMehr als 20 Platform Builds pro Monat?
Lass uns sprechenSei dabei, wenn Jardis startet.
Trag dich ein. Du bekommst Zugang, sobald wir live gehen. Inklusive kostenlosem Trial.
Neugierig, wie Jardis funktioniert?
Jardis entdeckenHäufige Fragen
Antworten auf die wichtigsten Fragen zu Jardis und Laravel im DDD-Kontext.
Nein. Laravel bleibt für HTTP, Routing, Auth, Queues und alles andere zuständig, wofür es gebaut wurde. Jardis generiert ausschließlich die Domain-Schicht: PHP-Entities, Aggregates, Commands, Queries, Domain Events und die Repository Pipeline. Diese leben als eigenständige Packages neben Laravels app/-Verzeichnis.