Process-Designer
Teil des Designer-Guides. Voriger Schritt: Aggregate-Designer · Nächster: Rules & Governance.
Ein Prozess modelliert einen fachlichen Ablauf als Knoten-Graph. Er lebt auf Bounded-Context-Ebene, Geschwister der Aggregate, kein Unterpunkt eines Aggregats. Ein Prozess ruft ausschließlich die Command-/Query-API der Aggregate auf, nie direkt deren Datengraphen.
Der Graph
Der ganze gemalte Graph ist ein Workflow. Knoten sind über Kanten verbunden, Kanten tragen Bedingungen: onSuccess führt weiter, onFail definiert den Fehlerpfad. Schleifen erkennt der Designer automatisch und markiert sie mit einem Badge.
Jeder Knoten trägt eine von sechs Knoten-Arten, wählbar im Knoten-Inspektor:
| Art | Bedeutung |
|---|---|
| Aktion | Hand-Code-Stub — der Ort für deine Fachlogik. |
| Sub-Prozess | Synchroner Aufruf eines anderen Prozesses (wartet; Events blubbern durch). Unterstützt onSuccess- und onFail-Routing. |
| Event ◇ | Feuert ein Domain-Event; der Ablauf läuft weiter (asynchron). |
| Cross-BC-Call | Ruft eine fremde Fassade + Methode — auch über Domänen-Grenzen. |
| Externer Call | Ein benannter Service auf gewählter Ebene (Prozess / BC / Domäne). |
| Rule | Bindet eine Regel aus dem Rules-Katalog in den Knoten (Warnung bei Doppelbindung). |
Ein Event ◇-Knoten trägt Label + Quelle: die Quelle ist entweder ein Feld des Prozess-Inputs oder das Ergebnis eines anderen Knotens („Ergebnis von Knoten" = letztes Ergebnis, „alle Ergebnisse" = Liste). Die zwei Standardfelder eventId und occurredAt sind automatisch und read-only.
Der Input
Ein Prozess besitzt kein Aggregat: sein Input ist deshalb self-contained und erweitert nie ein Aggregat-Command-DTO. Im eigenen Input-Tab definierst du Felder als Name | Typ | Wert:
- PHP-Skalare —
string,int,float,bool,array,mixed. - Command — genau ein DTO.
- Liste — 1..N DTOs.
Einstellungen
- In API sichtbar (Standard: an) — ausgeschaltet wird der Prozess zum reinen Sub-Prozess: nicht über die BC-Fassade erreichbar, nur als Sub-Prozess-Knoten nutzbar.
- Transaktion — der Ablauf läuft transaktional.
Report
Der Report-Tab zeigt den Build-Status (aktuell / Build nötig / Build blockiert) und die Referenz-Drift je Cross-BC-Aufruf: hat sich beim Produzenten die referenzierte Fassade/Methode geändert (Facade, Methode, Seite, Änderungsart)? Der Reconcile-Abgleich der Context-Map prüft dieselben realen Aufrufe gegen die deklarierte Kopplung.
Vom Modell zum Code
Ein Build erzeugt den Prozess unter {BC}/Process/{Name}/: DTO, Orchestrator und Knoten-Stubs (Generator-eigen). Aufgerufen wird er über die BC-Fassade:
$result = $bc->process()->{name}($dto);Deine Fachlogik lebt in den Aktion-Knoten-Bodies (…/Command/Handler/Action/, body-preserving beim erneuten Build) sowie in Query/, Repository/, Service/-Segmenten des Prozesses, diese legt der Generator nie an, sie gehören dir. Details in den Skills (platform-workflow, platform-cookbook).
Cross-BC-Write
Schreibend über eine BC-Grenze läuft nur über die fremde process()-Fassade, nie gegen die fremde Aggregat-Write-Fassade, und nie durch Durchreichen fremder DTOs. Der Cross-BC-Call übersetzt über einen generierten Service (Anti-Corruption-Layer).