Less reconciliation of meaning.
Teams can ask the same named question of the same model. A different screen does not need to invent a different definition of readiness, eligibility or completeness.
01 / Identity
First, a thing
that stays itself.
A name can change. A team can change. An application can be replaced. Stable identity lets the business keep talking about the same thing through all of it.
USEFUL ON ITS OWN
Recognise one thing across its changes.
STRONGER TOGETHER
Every fact, connection and accepted change has a stable subject. The object’s story stays attached to the object.
Without identity, correct information can still be attached to the wrong thing.
02 / Fields & evidence
Give it facts.
Keep their basis.
Fields describe what is known about the object. In DO, a fact is a known value with supporting evidence—or an explicit unknown with a reason. Its source matters as much as its value.
USEFUL ON ITS OWN
Capture information in a consistent shape.
STRONGER TOGETHER
Identity tells us what the information is about. Evidence tells us why it can be used, or why a conclusion must wait.
Missing is not zero. Conflicting sources do not become certainty simply because a field has room for only one value.
03 / Relationships
Connect the thing
to its context.
Business meaning rarely fits inside one record. Objects belong to, depend on, authorise, contain or fulfil other objects. A named relationship makes that connection explicit and can carry facts about the connection itself.
USEFUL ON ITS OWN
Describe how two things are connected.
STRONGER TOGETHER
Conclusions can depend on related evidence, not just local fields. The business becomes a graph of meaningful connections.
A relationship is more than a link on a screen. Its meaning, identity and permitted cardinality matter.
04 / Derived outcomes
Turn facts into
shared understanding.
“Complete”, “eligible” and “ready” are conclusions. Define each once from the relevant facts and relationships, then let applications ask for it by name. The answer can be true, false or unknown.
USEFUL ON ITS OWN
Calculate a useful answer.
STRONGER TOGETHER
The same meaning can inform a screen, a semantic query and a command rule. Follow its dependencies back to the evidence to understand why.
An outcome is computed, not another editable flag. It must not become a competing source of truth.
05 / Lifecycle
Give change
a shape.
A status tells you where something is. A lifecycle defines which moves are legal from there. The business authors the possible states and transitions; an arbitrary status edit does not create a valid transition.
USEFUL ON ITS OWN
Describe the legitimate progression of a thing.
STRONGER TOGETHER
Facts and outcomes tell us its condition. Lifecycle tells us which futures are permitted from its current position.
Not every fact change is a lifecycle transition. Both still need a governed path to change.
06 / Constraints & invariants
Make the promises
enforceable.
A constraint asks whether a particular change may happen. An invariant asks whether the resulting state is valid. Both must be established as true before their governed change can commit.
USEFUL ON ITS OWN
Express a business requirement.
STRONGER TOGETHER
Rules use facts, related context and outcomes to protect every applicable change path—not just the most obvious button.
A check at one doorway cannot protect every later edit. Invariants guard candidate state even when the lifecycle does not move.
07 / Commands & authority
Ask for change.
Let the model decide.
A command expresses intent: create, amend, assign, activate, close. It carries validated inputs and can be refused. The runtime evaluates the request against the model and the supplied actor’s authority.
USEFUL ON ITS OWN
Name what someone wants to do.
STRONGER TOGETHER
Lifecycle, conditions and authority determine what this actor may attempt. The same decision boundary serves a person, an integration or automation.
A displayed action is a preview. Execution rechecks current state; a stale screen cannot grant permission.
08 / Events & provenance
Remember the change.
Preserve the reason.
An accepted command proposes events. Once committed, those events record what changed. Current state is built from that accepted history; later corrections add new history rather than silently rewriting what happened.
USEFUL ON ITS OWN
Keep a record of a change.
STRONGER TOGETHER
Facts gain a causal history. Conclusions explain why they hold; events explain how the object reached its current state.
A request is not an event. A proposed event is not durable until persistence succeeds.
09 / Durability & consistency
Make it last beyond
the application.
With a durable persistence host, accepted events and command receipts survive restarts and lost responses. Version checks prevent a decision based on stale observations from becoming a committed change.
USEFUL ON ITS OWN
Retain information after the session ends.
STRONGER TOGETHER
The object keeps its identity, accepted state and history. Repeating the same complete intent and command identity recovers its receipt instead of repeating the business change.
The in-memory host is temporary. Durable storage, backups and recovery must be chosen and operated; the object need not run continuously.
10 / Effects & recovery
Let the world react
to an established fact.
A durable event can cause an external action: notify, schedule or update another system. Delivery happens after the business change is recorded and has its own retry and reconciliation path.
USEFUL ON ITS OWN
Connect one system to another.
STRONGER TOGETHER
Business truth and delivery status stay distinct. A failed notification does not erase an accepted change. New information returns through a new command.
An effect is a boundary capability, not a ninth core primitive. External delivery still needs workers and idempotent destinations.
11 / The connected business
Now the pieces
work together.
One object’s accepted change can alter the evidence relevant to another. Outcomes are reevaluated; different commands become available. A business process can be understood as permitted changes across a graph of durable objects.
USEFUL ON ITS OWN
Each object describes one meaningful thing.
STRONGER TOGETHER
People, applications and automation coordinate around a common model of what is known, what follows, what may happen and what did happen.
The model defines the meaning. It does not make every related change one global transaction or automatically operate every workflow.