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 erzeugt 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 erzeugt 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 erzeugte 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, erzeugten Architektur.
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 erzeugt die DDD-Infrastruktur, dein Laravel-Team schreibt direkt die Business-Regeln, die euer Produkt ausmachen.
Domain-Logik unabhängig von Laravel
Der erzeugte 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 WaitlistHä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 erzeugt 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.