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 a surface, interface, or port. A boundary separates scopes; a surface is a typed abstraction of the externally relevant semantics presented at that cut; an interface is a reusable intentional interaction type projected on a surface; and a port is a particular occurrence through which the bounded system provides or requires that interface. One boundary may expose no surface, one surface, or several audience-relative surfaces, and each surface may contain several provided and required ports.

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 semantic 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.
Semantic process boundaries: define the identity, participants, authority, purpose, and completion meanings of coherent work unfolding over time.
Workflow or process-structure boundaries: define the authored control, data, resource, exception, and event-log structures used to describe progression without making that structure the semantic process itself.
Saga or business-recovery boundaries: define which partial completions, compensation decisions, alternate paths, reconciliation, escalation, and completion meanings belong to one business-recovery process.
Durable-execution and execution-recovery boundaries: define which execution history, checkpoints, timers, retry state, signals, and pending work survive interruption and resume the same logical computation without deciding its business-recovery meaning.
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.