Process Designer
Part of the Designer guide. Previous: Aggregate Designer · Next: Rules & Governance.
A process models a business flow as a node graph. It lives at bounded-context level, sibling of the aggregates, not a sub-item of an aggregate. A process exclusively calls the command/query API of the aggregates, never their data graphs directly.
The Graph
The whole drawn graph is a workflow. Nodes are connected via edges, edges carry conditions: onSuccess continues, onFail defines the error path. The Designer detects loops automatically and marks them with a badge.
Every node carries one of six node kinds, selectable in the node inspector:
| Kind | Meaning |
|---|---|
| Action | Hand-code stub — the place for your business logic. |
| Sub-Process | Synchronous call of another process (waits; events bubble through). Supports both onSuccess and onFail routing. |
| Event ◇ | Fires a domain event; the flow continues (asynchronous). |
| Cross-BC Call | Calls a foreign facade + method — even across domain boundaries. |
| External Call | A named service at a chosen level (process / BC / domain). |
| Rule | Binds a rule from the rules catalog into the node (warns on double binding). |
An Event ◇ node carries a label + source: the source is either a field of the process input or the result of another node ("result of node" = last result, "all results" = list). The two standard fields eventId and occurredAt are automatic and read-only.
The Input
A process owns no aggregate: its input is therefore self-contained and never extends an aggregate command DTO. In its own Input tab you define fields as Name | Type | Value:
- PHP scalars —
string,int,float,bool,array,mixed. - Command — exactly one DTO.
- List — 1..N DTOs.
Settings
- Visible in API (default: on) — switched off, the process becomes a pure sub-process: not reachable via the BC facade, usable only as a sub-process node.
- Transaction — the flow runs transactionally.
Report
The Report tab shows the build status (current / build needed / build blocked) and the reference drift per cross-BC call: has the referenced facade/method changed on the producer side (facade, method, page, kind of change)? The Context Map's Reconcile check checks the same real calls against the declared coupling.
From Model to Code
A build generates the process under {BC}/Process/{Name}/: DTO, orchestrator and node stubs (generator-owned). It's called via the BC facade:
$result = $bc->process()->{name}($dto);Your business logic lives in the action node bodies (…/Command/Handler/Action/, body-preserving on rebuild) as well as in the Query/, Repository/, Service/ segments of the process, the generator never creates these, they belong to you. Details in the skills (platform-workflow, platform-cookbook).
Cross-BC Write
Writing across a BC boundary runs only via the foreign process() facade, never against the foreign aggregate write facade, and never by passing through foreign DTOs. The cross-BC call translates via a generated service (anti-corruption layer).