Business systems should perform actions — not receive arbitrary database edits
When a real business creates an order, closes an opportunity or posts an invoice, it does not conceptually say:
Change column X in table Y.
It performs a business action.
Metrolane models mutations the same way.
Commands express business intent
Conceptually:
- Close opportunity
- Create sales order
- Post invoice
- Receive goods
- Terminate worker
A command says:
This business action should occur.
The handler owns the rules for making it happen.
Handler flow
A typical mutation path is:
- authorize
- validate
- check idempotency
- begin transaction
- change source-system state
- write audit/event
- store result
- commit
That keeps business rules in one controlled place.
Why this matters
Different callers can use the same mutation path:
- UI
- seed process
- tests
- relay
- simulator
- future action tool
The caller changes.
The business rule does not.
CRM to ERP
A CRM opportunity can become an ERP Sales Order through an explicit operational handoff.
Example:
OPPORTUNITY_TO_SALES_ORDER · INTEGRATION_RELAY
Cross-system handoff is not entity resolution
is a business-process handoff.
is identity resolution.
The arrows may look similar in a diagram.
Their meaning is completely different.
One source record, two kinds of connection
Use:
It can show:
Events and relays
A command can produce an event representing something that happened.
A relay can then carry an eligible business fact into another system.
Conceptually:
- CRM command
- CRM state changes
- event / outbox
- relay discovers eligible work
- ERP command
- ERP state changes
This preserves the important boundary:
One source system does not directly rewrite another source system's tables.
Idempotency
A business command should be able to answer:
Without that, retries can create duplicate orders, duplicate postings or duplicate integration effects.
Idempotency is therefore part of the business mutation contract, not an afterthought.
Why the simulator must use handlers too
A tempting simulator design would be:
- generate event
- directly insert rows into source tables
Metrolane avoids that.
The simulator should be just another caller:
- Simulator
- Business command
- Handler
- Source-system mutation
Otherwise the simulated company would follow different business rules from the normal company.
That becomes especially important in Phase 10.
Chapter takeaway
- Commands express business intent.
- Handlers own authorization, validation, idempotency and mutation.
- Relays carry business facts across system boundaries.
- Operational handoffs remain distinct from identity resolution.
- The simulator and future AI actions should use the same governed mutation path.