The UI/IO boundary layer

2026-03-02 00:53:11.541Z

The UI/IO boundary layer is the outermost layer of an
Event Model. It is where external signals originate
and where projections are consumed. It is the boundary
between the system and everything outside it.

What This Layer Actually Is

Colloquially this layer is called "UI" or "screens."
These terms are common and accepted but they understate
what this layer represents. Any actor or signal can
occupy this layer:

A human clicking a button or filling a form
A command line entry
A POST to a REST API
A message from an external system or processor
A scheduled or automated process
An AI agent issuing an instruction
Any IO boundary between the system and the outside
world

The layer is not the interface. It is the boundary.
The distinction matters because it determines what
belongs here — not just human-facing screens, but
every point where something external communicates
with the system or receives communication from it.

The IO Perspective

NEXUS treats this layer explicitly as the IO boundary
of the system. This is a deliberate extension of Adam
Dymetrik's Event Modeling methodology.

In conventional Event Modeling the top layer is
primarily understood as the user interface — screens,
interactions, the human experience. NEXUS broadens
this to include all external communication: inbound
signals that trigger commands and outbound projections
that inform external consumers.

This has a specific implication for external events.
Rather than distinguishing internal and external events
at the event layer, NEXUS places the external boundary
here. External signals — from other systems, third-party
services, external processors — enter through this
boundary layer, trigger commands, and those commands
produce internal events. The event layer remains clean
and fully owned. There are no external events in a
NEXUS system — only external signals that cross the
boundary and become internal commands.

What Happens at This Layer

Two things happen at the UI/IO boundary:

Initiation — something external decides to act.
A human makes a decision. A process reaches a
trigger condition. An external system sends a
signal. That decision or signal becomes a command
directed at the system. The boundary layer is where
the decision happens — not inside the system, but
at its edge.

Reception — a projection produces derived state
and that state is consumed at the boundary. A human
reads a screen. An API consumer receives a response.
An external processor receives an updated state.
The boundary layer is where projections land and
become useful.

Relationship to Commands and Projections

The boundary layer connects to the triad in a
specific direction:

Boundary → Command — initiation flows inward.
Something at the boundary triggers a command that
enters the system.
Projection → Boundary — reception flows
outward. A projection produces state that crosses
the boundary to a consumer.

The boundary layer does not produce events directly.
It produces commands. Commands produce events. This
indirection is intentional — it keeps the event layer
clean and ensures every fact recorded in the system
passed through a command that could validate,
transform, and own it.

Swim Lanes at the UI/IO Layer

Swim lanes at this layer separate different actors
and personas horizontally. Each lane represents a
different kind of thing that can initiate commands
or receive projections:

Generic user
Admin or privileged user
REST API consumer
External processor or service
Scheduled or automated process
AI agent

Swim lanes make it explicit which actors participate
in which slices of the model. A command slice in the
admin lane is only triggerable by an admin. A
projection slice in the API lane is only consumed
by API consumers. The lane is the actor's row in
the timeline.