The Command / Event / Projection triad

2026-03-01 22:55:31.848Z2026-03-01 23:06:49.289Z

The three core elements of an Event Model are Command,
Event, and Projection. The names are deliberate. Each
describes the mechanism of the thing, not just its
purpose. Understanding why the names were chosen is
part of understanding how the system works.

The Triad

Command — the mechanism of intent. A function.
Something external to the system wants something to
happen and issues a command to make it so. A command
carries input, applies logic, and produces an event
if accepted. It is deterministic — given the same
input and same system state, it produces the same
result. It may contain branching logic and multiple
output paths, but it is always a function: input in,
result out.

Event — the mechanism of fact. Not a function —
a fact. Something happened. It is recorded
permanently and immutably. An event is never updated,
never deleted, only appended to the log. Events are
the only source of truth in the system. Everything
else — current state, projections, read views — is
derived from events. The event answers the question:
what actually happened?

Projection — the mechanism of derived state. A
function. Takes one or more events as input and
produces a view of current state for a consumer.
Like commands, projections are deterministic and
repeatable — given the same events in the same order,
a projection always produces the same result. A
projection is never the source of truth. It is always
derived. It can be discarded and rebuilt from the
events at any time with identical results.

Why the Names Are Mechanistic

All three terms describe how the thing works, not
just what it's for. This is deliberate.

Compare alternative terms that describe purpose
instead of mechanism:

Request instead of Command — describes what
the caller is doing, not what the system does with
it. A request might be ignored. A command is
handled.
Record or Log Entry instead of Event —
describes storage, not the fact itself. A log entry
is incidental. An event is the thing that happened.
Read Model instead of Projection — describes
the consumer's relationship to it (they read it),
not how it comes to exist. A read model could
theoretically be stored and mutated. A projection
cannot — by definition it is derived.
View instead of Projection — describes the
UI relationship, not the mechanism. Loses the
derivation constraint entirely.

Mechanistic names carry the constraint with them.
When you call something a Projection, you cannot
forget that it is derived. When you call something
an Event, you cannot forget that it is immutable.
The name enforces the concept every time it is used.

Consistency Across the Triad

The triad is internally consistent in a way that
aids learning and reasoning:

| Element    | Type     | Source        | Mutable? |
|------------|----------|---------------|----------|
| Command    | Function | External      | N/A      |
| Event      | Fact     | Command       | No       |
| Projection | Function | Events        | No       |

Commands and Projections are both functions —
deterministic, repeatable, logic-capable. Events
are facts — immutable, permanent, the source of
truth. The asymmetry between functions and facts
is the core of event sourcing. The triad makes
it explicit and nameable.

Aliases You Will Encounter

In broader literature and other methodologies,
these concepts appear under different names:

Projection is also called:

Read Model — in CQRS (Command Query
Responsibility Segregation) literature
View — in some frontend and database contexts
Query Model — in some DDD (Domain Driven
Design) contexts

Command is sometimes called:

Intent — in some event sourcing frameworks
Message — in message-driven architectures
Action — in some frontend state management
systems (Redux etc.)

Event is fairly consistent across literature,
though sometimes qualified as Domain Event to
distinguish from infrastructure or system events.

NEXUS uses Command, Event, and Projection as its
canonical terms. When reading external material,
these aliases help connect the concepts.

The Fourth Element

The triad operates within a fourth element — the
UI/IO boundary layer. This is where commands
originate and where projections are consumed. It
is not part of the triad because it is the boundary
of the system, not a mechanism within it. But it
is essential context for understanding how the
triad operates in practice.