Rules & Governance
Part of the Designer guide. Previous: Process Designer · Next: Code, API & Reports.
Rules anchor business rules to the commands of a bounded context. Two surfaces interlock: Governance (on the bounded context) holds the strategic policies, the Rules surface the rule catalog together with its bindings.
The Anchoring Chain
Policy → Rule → Command. A rule can optionally reference a policy; a rule gets bound into the rule chain of a command; a command carries zero, one or several rules in a fixed, reorderable order.
The heart of the Rules surface is a three-column board:
| Column | Content |
|---|---|
| Policies | The strategic mandates of the BC. |
| Rules | The rule catalog. |
| Commands | All commands of the BC, grouped per aggregate — including unbound ones. |
Connections are made via drag & drop or click. A side panel per selection maintains the details: for a rule the name, description, policy reference and deletion (with an impact preview); for a command the reorderable rule chain plus the expose toggle; for a policy the read-only text with a jump to Governance.
Status at a Glance
- Policy — "no rule anchoring" (red) or "without enforcement point" (orange). An enforcement point counts every bound command plus every rule-node usage in processes.
- Rule — "unused", "without strategic anchoring", a dangling policy reference, double binding, or "not determinable".
- Command — "without rule" or expose indicator.
For policies there is a phrasing template ("IF [condition], THEN [effect], UNLESS [exception]") with a non-binding hint linter that never blocks saving.
Report
The report is a read-only drift report with three finding kinds: policy without rule, rule without policy and empty chain. For "policy without rule" there's the quick action "create rule".
From Model to Code
Binding a rule into the chain of a command generates a guard check in the generated code that runs before the command executes. If the call violates the rule, it ends as a DomainResponse with status 422 (RuleViolation).
The {BC}/Rule/ catalog is generated: the rule body ({Name}.php) belongs to you (your rule logic), the guard/result pair is hermetic. A command with expose: true additionally gets a direct method on the BC facade ($bc->{command}($dto)), which still passes through the guard chain.
Two Guardrails
A rule reads state only via its own BC read facade (no cross-BC import). And: binding the same rule both as a process rule node and in the command chain warns about redundant double execution.
Details in the skills (platform-implementation, platform-cookbook).