Der Designer
Jardis ist eine visuelle Plattform. Im Designer (jardis ui) modellierst du deine Domäne auf zwei Ebenen: strategisch die Landschaft (welche Kontexte es gibt, wie sie zusammenhängen, welche Sprache und welche Regeln gelten) und taktisch die Umsetzung (Aggregate und Prozesse). Aus beidem erzeugt ein Build produktionsreifen DDD-Code. Diese Übersicht ist nach genau diesen beiden Ebenen gegliedert; jede Oberfläche hat ihre eigene Detailseite. Dieselben Schritte laufen headless über den MCP-Server.
jardis uiWorkspace-Board
Der Einstieg: Ein Workspace ist ein Verzeichnis mit einer oder mehreren Domänen. Je Domäne zeigt das Board die strategische Struktur in Spalten: Subdomains → Bounded Contexts → Aggregates → Rules → Prozesse. Von hier springst du in jede Detail-Oberfläche.
Strategisches Design (DDD)
Bevor eine Zeile Code entsteht, klärt strategisches DDD die Landschaft: welche Bounded Contexts es gibt, wie sie zusammenhängen, welche Sprache in ihnen gilt und welche fachlichen Regeln sie binden.
Context-Map
Die Beziehungen zwischen Bounded Contexts, mit den kanonischen DDD-Mustern. Drei Sichten: Strategic (Domain-Klassifikation Core/Supporting/Generic), Tactical und Reconcile, der Drift-Check, der deklarierte gegen reale Kopplung prüft und einen Findings-Report liefert.
Steckbrief (Bounded Context)
Der Steckbrief beschreibt einen Bounded Context strategisch: Business Model, Domain-Achse (Core/Supporting/Generic), Evolution und Owner. Auf derselben Seite liegen außerdem Schema (die Tabellen des Kontexts) und Mapping (DB-Spalte auf Fachname).
Governance
Der Governance-Tab hält die strategischen Policies des Kontexts: BC-weite, übergreifende Entscheidungen (z. B. „GDPR-bound", „B2B only"), keine Prozessregeln und keine Aggregat-Invarianten. Jede Policy zeigt ihren Abdeckungs-Status. Wie aus diesen Policies durchsetzbare Regeln an den Commands werden, zeigt das taktische Rules & Governance.
Glossar (Ubiquitous Language)
Das Glossar hält die verbindliche Sprache eines Kontexts: je Zeile Fachname | Beschreibung | Code-Bezeichner. Diese Ubiquitous Language speist die Autovervollständigung im Mapping und landet als Fachname im generierten Code.
Taktische Umsetzung
Innerhalb eines Bounded Context wird es konkret: Aggregate halten die Daten und ihre Invarianten, Prozesse verketten die fachlichen Abläufe, und Rules binden die strategischen Policies als Guards an die Commands. Aus allem erzeugt der Build den Domain-Code.
Aggregate-Designer
Pro Aggregate legst du fest, welche Tabellen dazugehören, welche Entität die Root ist und wie sie zusammenhängen, als ER-Diagramm mit PK/FK/UK-Markierungen. Die Tabs führen von Tables über den Designer zum generierten Code, den API-Specs und dem Report. Build erzeugt den Code-Baum.
Process-Designer
Fachliche Abläufe modellierst du als Knoten-Graph: jeder Knoten routet über onSuccess/onFail, liest cross-BC, ruft Rule-Ketten auf und verkündet am Ende Events. Ein terminaler Abweisungs-Knoten fängt alle Fehlerpfade.
Rules & Governance
Hier werden die strategischen Policies über Rules an die Commands der Aggregate gebunden: Policy → Rule → Command. Eine gebundene Rule wird im generierten Code zur Guard-Prüfung vor dem Command. Das Drei-Spalten-Board zeigt In-use- und Anchoring-Status.
Code, API & Reports
Nach dem Modellieren prüfst du das Ergebnis direkt im Designer, ohne in die IDE zu wechseln.
Der Code-Tab zeigt den generierten Aggregate-Baum, read-only im Browser:
Der API-Tab zeigt die Oberfläche des Aggregats: Commands/Queries mit ihrer Regelkette, Entity-Baum und Lebenszyklus-Events.
MCP — headless
Denselben Workspace steuerst du ohne Browser über den MCP-Server:
jardis mcpTools sind Aktionen (designen, bauen), Resources sind Read-only (Schema, Code lesen). Der AI-Agent durchläuft dieselbe Sequenz: Workspace → Schema → Design → Build → Code lesen. Alle Details auf der MCP-Seite.