Slice patterns — the two fundamentals and how they compose

A slice is a vertical cut through the Event Model
timeline that connects the layers. Every interaction
the system supports is expressed as one or more slices.
There are exactly two fundamental slice types. All
more complex patterns are compositions of these two.

The Two Fundamentals

Command slice

The flow is: UI/IO boundary → Command → Event.

Something external decides to act. A command is
issued. The system records that something happened.
This is the write path — the mechanism by which
the outside world causes facts to be recorded in
the system.

A well-formed command slice produces one event.
A command that produces multiple events is an
anti-pattern worth examining — it usually indicates
either that the command is doing too much, that
the events should be consolidated, or that what
appears to be one action is actually multiple
distinct actions that should be modeled separately.

Projection slice

The flow is: Event/s → Projection → UI/IO boundary.

Something happened in the system. A projection
derives state from that event or events and
delivers it to a consumer at the boundary. This
is the read path — the mechanism by which the
system informs the outside world of its current
state.

A projection slice can draw from any events in
the log — not just the most recent. A projection
might combine events from across the entire
history to produce its output. It might ignore
most events and only care about one specific
type. The projection defines what it needs;
the event log provides it.

Why Only Two

Many treatments of Event Modeling identify more
slice types — automation slices, translation
slices, and others. When examined carefully,
these decompose into combinations of the two
fundamentals. An automation slice is a projection
slice whose consumer happens to be an automated
process rather than a human — the projection
informs the boundary, and something at the
boundary issues a new command. That is a
projection slice followed by a command slice.

Keeping the model at two fundamentals has practical
benefits:

• The model stays tractable. Every slice has a
  clear type and a clear flow direction.
• Complexity is visible. A pattern that requires
  five slices is visibly more complex than one
  that requires two. That complexity is a signal,
  not just an implementation detail.
• Analysis is consistent. Asking "is this a
  command slice or a projection slice?" is always
  answerable. Asking "which of the seven slice
  types is this?" introduces ambiguity.

Multi-Slice Patterns

Real systems contain interactions that require
multiple slices in sequence. These are multi-slice
patterns — compositions of the two fundamentals
rather than new slice types.

A common pattern:

1. Command slice — user action produces an event
2. Projection slice — event updates a projection
   that the UI consumes
3. Command slice — the updated UI state enables
   a new user action that produces another event

This is three slices: command, projection, command.
Each slice is a fundamental. The pattern is their
composition.

Another common pattern involves automation:

1. Projection slice — events feed a projection
   consumed by an automated process at the boundary
2. Command slice — the automated process issues
   a command based on the projected state
3. Projection slice — the resulting event updates
   a projection consumed by the UI

Three slices again: projection, command, projection.
The automation is not a special slice type — it is
an actor at the UI/IO boundary that happens to be
a process rather than a human.

External IO and the Slice Model

External signals from outside the system — other
services, third-party APIs, external processors —
enter through the UI/IO boundary layer and become
command slices. They do not become events directly.
The external signal crosses the boundary, triggers
a command, and that command produces an internal
event.

This keeps the event layer clean and fully owned.
The complexity of external IO is absorbed at the
boundary. The event layer sees only the internal
facts that commands have validated and recorded.

Reading a Model

When reading an Event Model timeline, slices are
the unit of analysis. For each vertical cut:

1. Identify the type — command slice or projection
   slice
2. Identify the actor — which swim lane at the
   UI/IO layer initiates or receives
3. Identify the events — which events are produced
   or consumed
4. Check for gaps — is every command slice followed
   eventually by a projection slice that informs
   someone of the result? Is every projection slice
   fed by events that are actually produced somewhere
   in the model?

Gaps found this way are design gaps — things the
system cannot do that it needs to be able to do,
or things it does that nothing consumes.

See Also

• Event Modeling as the design foundation
• The Command / Event / Projection triad
• The UI/IO boundary layer
• NEXUS → Swim lanes — actor boundaries and
  system boundaries
• NEXUS → Paths as first-class artifacts