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 generiert die Domain-Architektur, die Symfony nicht mitliefert.
Eigene Domain Entities neben Doctrine
Der Builder generiert 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.
Generierte Commands, Queries und Events statt manueller Verkabelung
Jardis generiert 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.
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 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 generieren. 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 generiert konsistente Architektur. Neue Entwickler finden sich sofort zurecht, weil jede Domain gleich aufgebaut ist.
Bereit, DDD in euer Symfony-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 Symfony im DDD-Kontext.
Nein. Symfony bleibt für HTTP, Routing, Dependency Injection, Security und Messaging zuständig. 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 Symfonys src/-Verzeichnis.