Skip to content

Code, API & Reports

Teil des Designer-Guides. Voriger Schritt: Rules & Governance · Zur Übersicht.

Nach dem Modellieren prüfst du das Ergebnis direkt im Designer: Code, API-Oberfläche und Befunde, ohne in die IDE zu wechseln.

Der generierte Code-Baum im Code-Tab

Code-Viewer

Der Code-Tab zeigt den generierten Code read-only im Browser, mit Syntax-Highlighting für PHP und YAML. Das Ergebnis eines Builds ist damit ohne IDE-Wechsel prüfbar. Der Baum ist hermetisch: geändert wird am Modell, nicht am Generat.

API-Ansicht

Die read-only Aggregat-API-Ansicht

Der API-Tab ist die read-only Sicht auf die Oberfläche eines Aggregats, in drei Spalten:

  • Commands / Queries des Aggregats, inklusive gebundener Regelkette und Expose-Status (mit Link zur Regelpflege).
  • Entity-Baum.
  • Lebenszyklus-Events.

Der Build erzeugt zusätzlich die formalen API-Spezifikationen aus denselben Definitionen: OpenAPI 3.1, AsyncAPI 3.0 und Protocol Buffers 3, immer synchron. Der Überblick dazu steht in den Highlights.

Validierung

Der Validierungs-Tab fasst Validator-, Designer- und Schema-Befunde in vier Kategorien zusammen: Fehler / Warnungen / Vorschläge / Übersteuert. Ein Vorschlag lässt sich per Dialog mit Pflichtbegründung übersteuern. Die Ausnahme landet dauerhaft und dokumentiert in der Schema-Konfiguration.

Build

Ein Klick auf Build erzeugt den Code-Baum. Der Ablauf:

  1. Vorab-Validierung — Fehler erscheinen sofort, nicht erst nach halbem Build.
  2. Live-Status je Pipeline-Stufe — über Server-Sent-Events, Stufe für Stufe.
  3. Abbrechen — der Abbrechen-Knopf stoppt sauber zwischen den Stufen.

Build-Bereitschaft: Jedes Aggregat und jeder Prozess weiß, ob sein Entwurf seit dem letzten erfolgreichen Build verändert wurde. Der Report zeigt aktuell / Build nötig / Build blockiert; der Build-Knopf ist nur aktiv, wenn ein Build wirklich nötig ist.

Entwurf blockiert den Build

Ein Aggregat mit offenem Entwurf ist zusätzlich build-blockiert, unabhängig vom Drift-Status, an jedem Einstiegspunkt. Headless meldet sich das als DRAFT_EXISTS (MCP). Siehe Aggregate-Designer.

Für Prozesse zählt zusätzlich die Referenz-Drift: ob sich ein referenzierter Cross-BC-Aufruf beim Produzenten geändert hat (Hash-Vergleich). Denselben Abgleich auf Domänen-Ebene macht der Reconcile-Check der Context-Map.