DDD mit Symfony. Ohne alles selbst zu bauen.
Symfony bringt Doctrine, Messenger und Dependency Injection mit. Aber keine Architektur für Bounded Contexts und keine klare Trennung von Domain und Infrastructure. Jardis ergänzt genau diese Schicht.
Symfony gibt dir Werkzeuge. Aber nicht die Architektur.
Doctrine ist ein guter Data Mapper. Messenger ist ein solider Bus. Aber DDD ist mehr als Werkzeuge. Es ist Struktur.
Doctrine Entities sind keine Domain Entities
Doctrine-Mapping-Annotationen, Lifecycle-Callbacks und Flush-Zyklen durchziehen deine Entities. In der Praxis vermischt sich Persistenz-Logik mit Business-Regeln. Die Domain-Schicht wird abhängig von Doctrine, obwohl sie es nicht sein sollte.
Wochen Boilerplate pro Bounded Context
Commands, Handlers, Events, Repositories, API Contracts: alles per Hand. Jeder neue Bounded Context bedeutet Dutzende Dateien, die manuell angelegt, verkabelt und konsistent gehalten werden müssen. Das kostet Wochen, nicht Minuten.
Bounded Contexts existieren nur auf dem Whiteboard
Symfonys Bundles sind keine Bounded Contexts. In der Praxis landen Entities, Services und Repositories im selben src/-Verzeichnis. Domain-Grenzen sind Ordner-Konventionen, die bei Zeitdruck niemand einhält. Ein Service greift auf drei Domains zu, und niemand merkt es.
Wie Jardis DDD in Symfony-Projekte bringt.
Symfony bleibt für HTTP, Routing, DI und Messaging zuständig. Jardis erzeugt die Domain-Architektur, die Symfony nicht mitliefert.
Eigene Domain Entities neben Doctrine
Der Builder erzeugt 3-Layer Entities als eigenständige PHP-Packages. Deine Domain-Logik lebt getrennt von Doctrine-Mappings. Persistenz wird zur Infrastruktur-Aufgabe, die Domain bleibt sauber. Doctrine bleibt als Persistenz-Layer erhalten, diktiert aber nicht mehr deine Architektur.
Erzeugte Commands, Queries und Events statt manueller Verkabelung
Jardis erzeugt die komplette CQRS-Infrastruktur in PHP: Commands, Command Handlers, Queries, Query Handlers und Domain Events. Das Ergebnis ist kompatibel mit Symfony Messenger, aber die Struktur kommt aus dem Builder. Kein manuelles Anlegen von Handler-Klassen für jeden Use Case.
Physische Domain-Grenzen statt Ordner-Konventionen
Jeder Bounded Context wird ein eigenständiges PHP-Package mit eigener Dependency-Struktur. Der Builder erzwingt Isolation auf Dateisystem-Ebene. Ein Service kann nicht versehentlich auf eine fremde Domain zugreifen. Das ist keine Guideline, sondern Architektur.
Warum Symfony-Teams Jardis für DDD einsetzen.
Nicht weil Symfony falsch ist. Sondern weil DDD-Architektur mehr verlangt, als Symfony mitbringt.
Bounded Contexts als PHP-Packages
Jede Domain wird ein eigenständiges Package mit eigener Struktur. Order, Payment, Compliance: physisch getrennt statt in einem src/-Verzeichnis vermischt. Teams arbeiten unabhängig voneinander.
Domain-Architektur in Minuten statt Wochen
Neuer Bounded Context? Schema definieren, Builder starten, production-ready Code erzeugen. Kein wochenlanges Anlegen von Commands, Handlers, Events und Repositories per Hand.
Jeder Bounded Context folgt dem gleichen Pattern
Keine Diskussionen über Ordnerstruktur, Naming oder Layer-Aufteilung. Der Builder erzeugt konsistente Architektur. Neue Entwickler finden sich sofort zurecht, weil jede Domain gleich aufgebaut ist.
Bereit, DDD in euer Symfony-Projekt zu bringen?
Auf die WaitlistHäufige Fragen
Antworten auf die wichtigsten Fragen zu Jardis und Symfony im DDD-Kontext.
Nein. Symfony bleibt für HTTP, Routing, Dependency Injection, Security und Messaging zuständig. 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 Symfonys src/-Verzeichnis.