Architectural boundary

What it means

An architectural boundary establishes what a component owns and how other components interact with it. The boundary may be expressed through modules, APIs, services, packages, or team ownership. Good boundaries make allowed dependencies and stable contracts easier to see, while acknowledging that every boundary carries coordination cost.

Example

A reporting service reads an approved data contract instead of querying another service’s tables. The boundary lets the source evolve internally while preserving a consumer-facing interface.

Limitations

A boundary that exists only in diagrams can be bypassed in code or operations. Too many boundaries increase latency and deployment coordination. Evaluate actual dependency paths and change patterns.

How to use the signal

Name the owner, allowed dependency direction, and migration path before treating the boundary as enforceable design.

Weave can help compare boundary changes with review duration, blocked time, and rework. Use repository and runtime tools to verify enforcement, and treat Weave as context for the engineering consequences.