Commands, events and consistency

What this page covers

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

A formal operation, an execution attempt, a network request and an event each have their own meaning and identifier. This page states principles only; implementation details are not published.

Every formal object has one owner

A business fact is written only by the domain responsible for it. Other domains learn of changes through events and may update their own state or derived views, but never rewrite a fact they do not own.

State and event are committed together

A formal operation first checks permissions, object state and preconditions, then records the change in business state together with the events to be sent in a single commit, and only then sends them reliably. So neither “the state changed but the message was lost” nor “the message went out but the state did not change” can happen.

Duplicates, delays and reordering are normal

Events are delivered at least once and may repeat, arrive late or out of order. Receivers de-duplicate by event identifier and business key and check the object version, so an old version never overwrites a newer state.

Views are derived; key actions go back to the record

Home, workspaces, statistics and search are derived views. They may lag for a while, but they show when they were updated and never pose as real-time fact. Before an important action runs, the system goes back to the formal record and re-checks state and permissions.

Replaying is not redoing

Views can be rebuilt by replaying events by version, but external actions such as payments or publishing are never done a second time because of a replay. Failures are retried a bounded number of times, and what cannot be handled is set aside for a person; long flows across domains are closed out through state coordination and reconciliation, never by pretending to be one transaction. Events carry only the references they need, never keys or customer content.

Source

This page follows A24 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “Business domains and fact authority”; “State machines and exception paths”; “Versioning, maturity and roadmap”.