Boundaries

Boundaries define the scope and context in which observation, interpretation, authority, failure, persistence, delivery, and coordination apply.

At the structure level, boundaries describe semantic and operational scoping in the system graph, not a specific process, network, storage, or deployment mechanism.

A boundary is not necessarily an interface. A boundary separates scopes; an interface is a declared crossing at a boundary. One boundary may have several provided and required interfaces, and some boundaries intentionally expose none.

Scope answers what is included, excluded, owned, visible, controlled, or guaranteed. Context answers which meanings, policies, identities, versions, capabilities, assumptions, and authorities apply inside that scope.

As a modeling discipline, a boundary should be treated as a kind of universal construction only when its scope and context are determined by the relevant inclusions, exclusions, authorities, guarantees, and interaction edges.

Interpretation is performed by an observer relative to a boundary. An observer interprets values, observations, events, commands, and queries within the scope and context defined by that boundary.

An observer boundary determines whether an event is exogenous, input, endogenous, or output relative to that observer. It also frames which state is visible, which policies apply, which authority is available, which effects can be committed, and what command or query interpretation can mean.

Boundary types include:

Bounded contexts: define where one domain model and its ubiquitous language have consistent applicability and ownership. A bounded context may be reflected in team, code, service, or deployment boundaries without being identical to any of them.
Observer boundaries: define what an observer can see, interpret, authorize, and commit.
Entity or aggregate boundaries: define the subject whose state, invariants, transitions, and version history are controlled together.
Transaction and commit boundaries: define which reads, writes, and effects commit or roll back atomically.
Process or workflow boundaries: define the scope of a long-running behavior, its durable progress, retries, compensations, and recovery.
Service boundaries: define the semantic responsibility, authority, policy, dependencies, guarantees, and interfaces of a capability. Independent deployment or operation is a possible realization, not part of the unqualified definition.
Interface boundaries: define designed crossing points, their admitted interaction roles, and their semantic contracts.
Protocol and broker boundaries: define delivery, ordering, acknowledgment, retries, and message ownership for an interaction substrate.
Failure boundaries: define what can fail, restart, partition, or recover independently.
Persistence boundaries: define what is durably recorded and treated as recoverable truth.

Guarantees are meaningful only when their boundary is explicit. At-most-once delivery, ordering, acknowledgment, durability, and commitment can all refer to different boundaries.

Example

Consider a Kafka consumer that updates an entity in a database and writes an outbox record:

Kafka topic -> consumer service -> database transaction -> outbox -> downstream broker

Different guarantees apply at different boundaries:

At-most-once delivery may describe the broker/consumer boundary: once the consumer acknowledges or advances its offset, the broker may not redeliver the message even if processing later fails.
Ordering may be described with respect to the Kafka partition boundary. It does not imply global ordering or ordering across unrelated entity IDs.
Acknowledgment takes place at the broker protocol boundary. Committing an offset means the consumer accepted responsibility for the message, not necessarily that the domain transition committed.
Durability may describe Kafka log retention, database state durability, or outbox durability. These are separate persistence boundaries with different replication, retention, compaction, backup, and recovery policies.
Commitment may correspond to the entity or aggregate boundary. The business transition commits only when the entity accepts the command, records the new state or event, and advances the version.

So a system can acknowledge a message and preserve broker ordering while still failing to commit the domain transition. It can also receive the same message more than once while committing the domain transition only once through idempotency and concurrency control.