Reines PHP. Echte Architektur. Kein Framework dazwischen.
Du willst DDD ohne Framework-Abhängigkeit. Guter Instinkt. Aber alles selbst bauen heißt: Wochen für Infrastruktur, die keinen Business-Value liefert. Jardis erzeugt framework-agnostischen PHP-Code, der genau das tut, was du willst.
Framework-frei heißt nicht aufwandsfrei.
Der Wunsch nach purem PHP ist berechtigt. Aber ohne Tooling wird DDD zur Vollzeitbeschäftigung.
Jede Schicht von Grund auf
Kein Framework heißt: kein DI-Container, kein Event-Dispatcher, kein Routing. Du baust alles selbst. Repository-Interfaces, Command-Bus, Event-Handling. Bevor die erste Domain-Regel steht, hast du drei Monate Infrastruktur geschrieben.
Wissen lebt in einzelnen Köpfen
Ohne Framework gibt es keine Community-Konventionen. Jedes Team erfindet eigene Patterns für Repository-Abstraktion, Event-Publishing und Layer-Trennung. Neue Entwickler stehen vor einer individuellen Architektur, die nirgendwo dokumentiert ist.
Konsistenz stirbt mit dem ersten Zeitdruck
Aggregate Root-Patterns, Value Object-Validierung, Event-Naming: im Sprint-Stress schreibt jeder Entwickler es anders. Ohne erzwungene Struktur driftet die Architektur mit jedem Merge Request weiter auseinander.
Framework-agnostischer Code, der nicht von Hand entstehen muss.
Jardis erzeugt pures PHP. Keine Laravel-Abhängigkeit, keine Symfony-Abhängigkeit, keine Framework-Kopplung. Aber mit der Konsistenz, die manuelle Architektur nicht liefern kann.
Erzeugter Domänencode ohne Framework-Import
Der Jardis Builder erzeugt Bounded Contexts als eigenständige PHP-Packages. Keine Abhängigkeit zu Laravel, Symfony oder einem anderen Framework. Domain Entities, Value Objects, Aggregates, Commands, Queries und Events: reines PHP. Du bindest den Code in jedes Framework ein oder nutzt ihn standalone.
Hexagonale Architektur auf Dateisystem-Ebene
Manuelles DDD ohne Framework scheitert an fehlender Durchsetzung. Jardis erzwingt Layer-Grenzen physisch: Domain, Application und Infrastructure sind getrennte Verzeichnisse mit klaren Dependency-Regeln. Ein Import aus der falschen Schicht ist strukturell unmöglich, nicht nur unerwünscht.
CQRS, Events und Repository Pipeline ab Minute eins
Statt monatelang Command-Bus, Event-Dispatcher und Repository-Abstraktionen zu bauen, erzeugt der Builder die komplette Pipeline in PHP: Commands, Command Handler, Queries, Query Handler, Domain Events und die 5-Stage Repository Pipeline. Alles framework-agnostisch, alles sofort einsatzbereit.
Warum framework-agnostisches DDD mit Jardis besser funktioniert.
Nicht weil reines PHP falsch ist. Sondern weil die Infrastruktur-Arbeit dich davon abhält, Domain-Logik zu schreiben.
Kein Framework-Import in deiner Domain
Der erzeugte Code hat null externe Abhängigkeiten. Deine Domain-Logik bleibt portabel. Heute Symfony, morgen Laravel, übermorgen etwas Eigenes: die Domain bleibt identisch.
Gleiche Struktur in jedem Bounded Context
Keine individuellen Architekturen pro Domain. Jeder Bounded Context folgt derselben Package-Struktur, denselben Naming-Konventionen, derselben Layer-Aufteilung. Vorhersagbar für jeden Entwickler im Team.
Struktur die bleibt, auch unter Druck
Manuelle Architektur erodiert bei Zeitdruck. Der Builder erzwingt hexagonale Architektur auf Dateisystem-Ebene. Layer-Grenzen sind physisch, nicht dokumentiert. Keine Shortcuts möglich.
DDD in purem PHP, ohne alles selbst zu bauen?
Auf die WaitlistHäufige Fragen
Antworten auf die wichtigsten Fragen zu DDD ohne Framework mit Jardis.
Ja. Jardis erzeugt reines PHP ohne Abhängigkeiten zu Laravel, Symfony oder einem anderen Framework. Domain Entities, Value Objects, Commands, Queries und Events sind pure PHP-Klassen. Du kannst sie in jedes Framework einbinden oder standalone nutzen.