Swim lanes — actor boundaries and system boundaries

Swim lanes are horizontal lanes within a layer of the
Event Model timeline that separate different actors or
systems. They appear in two layers and mean different
things in each.

Swim Lanes at the UI/IO Layer

At the UI/IO boundary layer, swim lanes separate
actors and personas — the different kinds of things
that can initiate commands or receive projections.

Common lanes at this layer:

• Generic user — the standard human interacting
  with the system through its primary interface
• Admin — a privileged user with access to
  capabilities unavailable to generic users
• REST API consumer — an external system or
  developer accessing the system programmatically
• External processor — an automated system
  or service that interacts with the boundary
• Scheduled process — a time-triggered
  automation that issues commands or receives
  projections on a schedule
• AI agent — an AI system acting as an actor
  at the boundary, issuing commands or consuming
  projections

The lane a slice occupies at the UI/IO layer
defines who can participate in that slice. A
command slice in the admin lane is only
triggerable by an admin. A projection slice in
the API consumer lane is only consumed by API
consumers. The lane makes access and participation
explicit in the model rather than implicit in
implementation.

Why this matters

Without swim lanes, the model shows what the system
does but not who can do it. Two interactions that
look identical in structure may have completely
different access requirements. Swim lanes make
those requirements visible at design time — before
implementation — where they are cheap to reason
about and easy to change.

Swim Lanes at the Event Layer

At the event layer, swim lanes separate systems
within your controlled domain. When a model spans
multiple systems you own or build, each system
gets a lane showing which events it owns and
produces.

These are internal boundaries — all systems in
these lanes are within your domain, systems you
control, build, or govern. The lane is not an
external boundary. It is an ownership boundary
within your own architecture.

Common reasons for event layer swim lanes:

• Microservices — each service owns specific
  event types. The lane shows which service
  produces which events.
• Bounded contexts — in Domain Driven Design
  terms, different bounded contexts produce
  different events. The lane shows context
  ownership.
• Separate deployable systems — systems that
  are built and deployed independently but
  participate in the same overall model.

Why this matters

When a model spans multiple systems, knowing which
system owns which events is essential for
implementation planning. A command slice that
crosses system boundaries — a command in one
system producing an event owned by another — is
a design decision with significant implications.
Swim lanes make those crossings visible.

The Distinction

The key distinction to maintain:

Layer	Swim lane separates	Nature of boundary
UI/IO	Actors and personas	Access and participation
Event	Systems and services	Ownership and deployment

A swim lane at the UI/IO layer answers: who can
do this?

A swim lane at the event layer answers: which
system owns this?

Conflating the two leads to models that are harder
to read and reason about. Keep the distinction
explicit.

When to Add Swim Lanes

Swim lanes add clarity when the model has genuine
distinctions to express. They add noise when
applied uniformly without meaningful distinction.

Add UI/IO swim lanes when:

• Different actors have meaningfully different
  access to slices
• The model spans human and automated actors
• API access is a distinct concern from UI access

Add event layer swim lanes when:

• The model spans multiple systems you own
• Ownership of events is a meaningful design
  concern
• Deployment boundaries matter to the design

A simple model with one actor type and one system
does not need swim lanes. A complex model spanning
multiple actor types and multiple systems needs
them to remain readable.

See Also

• Event Modeling as the design foundation
• The UI/IO boundary layer
• Slice patterns — the two fundamentals and how they compose
• NEXUS → Paths as first-class artifacts