Die Herausforderung

DDD ist die Antwort auf nachhaltige Unternehmens-Software, seit über 20 Jahren. Aber die Umsetzung erfordert tiefes Architekturwissen, Disziplin über alle Schichten und konsistente Strukturen in jedem Projekt.

Das ist aufwendig und kommt genau deshalb viel zu selten zum Einsatz.

Die Antwort: Jardis

DDD ist über den Lebenszyklus die tragfähigere, wartbarere Wahl. Das ist es seit über 20 Jahren. Das einzige stichhaltige Gegenargument war stets der hohe Eintritts-Aufwand. Genau den senkt Jardis, den regelhaften Implementierungs-Anteil, ohne den Lebenszyklus-Vorteil anzutasten.

Jardis ist eine visuelle DDD-Plattform. Du modellierst deine Domäne im Designer: strategisch (Bounded Contexts, Glossar, Context-Map) und taktisch (Aggregate, Prozesse). Ein Klick auf Build erzeugt daraus die vollständige hexagonale Schicht: Entities, Aggregate, Commands, Queries, Events, Repository-Pipeline und API-Contracts.

Der Schnitt der Bounded Contexts und die Begriffe deiner Domäne bleiben menschliche Denkarbeit: Jardis erfasst sie, gleicht sie mit der taktischen Realität ab und nimmt dir die regelhafte Umsetzung ab.

Der Build arbeitet additiv: dein Custom-Code wird nie überschrieben. Im Designer ändern, Build läuft, fertig.

Änderung	Ohne Jardis	Mit Jardis
Neues Feld in einer Entity	Query, Transform, DTO, Validator, API-Spec — alles manuell	Im Designer ergänzen, Build läuft
Neue Entity im Aggregate	Dutzende Dateien manuell erstellen und konsistent halten	Tabelle ins Aggregat ziehen, Build läuft
Kardinalität ändert sich	Tief eingreifende Änderungen über die ganze Pipeline	Kanten-Kardinalität im Designer umschalten

Mit oder ohne eigenes Framework

Jardis zwingt dir kein Web-Framework auf. Für die HTTP-Anbindung liefert jardiscore/app Router, PSR-15-Pipeline und Envelope-Mapper gleich mit — genug für eine vollständige API. Bringst du bereits Laravel, Symfony oder Slim mit, übernimmt Jardis stattdessen ab dem Controller die fachliche Schicht. Beide Wege erfüllen denselben Envelope-Contract.

HTTP Request
  → jardiscore/app  (Router · PSR-15-Pipeline · Envelope-Mapper)
    │  — oder Laravel / Symfony / Slim / eigener Front-Controller
    ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄  Jardis-Domänenschicht  ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
    → Domain → Bounded Context → Query (lesen) · Process (schreiben) → DomainResponse

Kein Lock-in

Der erzeugte Code ist normales PHP. Zur Laufzeit kannst du jardiscore/kernel einsetzen oder einen eigenen Kernel implementieren. Alle Interfaces folgen PSR-Standards. Entscheidet ihr euch gegen Jardis, läuft euer Code weiter. Eure fachlichen Definitionen bleiben erhalten.

Framework-Freiheit: Heute Laravel, morgen Symfony, übermorgen etwas Eigenes. Jardis-Code läuft überall.

Jardis + KI

KI schreibt Code schneller als je zuvor. Aber bei Unternehmensanwendungen mit dutzenden Dateien wird jeder Interpretationsspielraum zum Risiko. Jardis eliminiert das strukturell:

• Keine Halluzinationen — der Platform Code definiert, was existiert. Die KI muss nicht raten.
• Keine Inkonsistenz — die Architektur erzwingt einen Weg. Jede Session, jeder Entwickler, dasselbe Ergebnis.
• Keine Nacharbeit — Skillsets und Quality Gates erzwingen Standards automatisch.