Rules & Governance

Teil des Designer-Guides. Voriger Schritt: Process-Designer · Nächster: Code, API & Reports.

Rules verankern fachliche Regeln an den Commands eines Bounded Context. Zwei Flächen greifen ineinander: die Governance (am Bounded Context) hält die strategischen Policies, die Rules-Fläche den Regel-Katalog samt Bindungen.

Die Verankerungskette

Policy → Rule → Command. Eine Rule kann optional auf eine Policy verweisen; eine Rule wird in die Regelkette (Chain) eines Commands gebunden; ein Command trägt null, eine oder mehrere Regeln in fester, umsortierbarer Reihenfolge.

Das Herz der Rules-Fläche ist ein Drei-Spalten-Board:

Spalte	Inhalt
Policies	Die strategischen Vorgaben des BC.
Rules	Der Regel-Katalog.
Commands	Alle Commands des BC, je Aggregat gruppiert — auch ungebundene.

Verbunden wird per Drag & Drop oder Klick. Ein Seitenpanel je Auswahl pflegt die Details: bei einer Rule Name, Beschreibung, Policy-Bezug und Löschen (mit Auswirkungsvorschau); bei einem Command die umsortierbare Regelkette samt Expose-Umschalter; bei einer Policy den read-only Text mit Sprung zur Governance.

Status im Blick

• Policy — „keine Rule-Verankerung" (rot) oder „ohne Wirkort" (orange). Ein Wirkort zählt jeden gebundenen Command plus jede Rule-Knoten-Nutzung in Prozessen.
• Rule — „ungenutzt", „ohne strategische Verankerung", hängender Policy-Bezug, Doppelbindung oder „nicht ermittelbar".
• Command — „ohne Rule" oder Expose-Kennzeichen.

Für Policies gibt es eine Formulierungsvorlage („WENN [Bedingung], DANN [Wirkung], ES SEI DENN [Ausnahme]") mit einem unverbindlichen Hinweis-Linter, der das Speichern nie blockiert.

Report

Der Report ist ein read-only Drift-Bericht mit drei Befundarten: Policy ohne Rule, Rule ohne Policy und leere Kette. Bei „Policy ohne Rule" gibt es die Schnellaktion „Rule anlegen".

Vom Modell zum Code

Die Bindung einer Rule in die Kette eines Commands erzeugt im generierten Code eine Guard-Prüfung, die vor Ausführung des Commands greift. Verletzt der Aufruf die Regel, endet er als DomainResponse mit Status 422 (RuleViolation).

Der {BC}/Rule/-Katalog wird generiert: Der Rule-Body ({Name}.php) gehört dir (deine Regel-Logik), das Guard-/Result-Paar ist hermetisch. Ein Command mit expose: true bekommt zusätzlich eine direkte Methode an der BC-Fassade ($bc->{command}($dto)), die trotzdem die Guard-Kette durchläuft.

Zwei Leitplanken

Eine Rule liest Bestand nur über die eigene BC-Read-Fassade (kein Cross-BC-Import). Und: Dieselbe Rule sowohl als Prozess-Rule-Knoten als auch in der Command-Kette zu binden, warnt vor redundanter Doppelausführung.

Details in den Skills (platform-implementation, platform-cookbook).