ALL-ARCH1002 · dependency_boundary_alignment
Judge whether dependencies honor one identified architectural boundary.
This is a contextual rule for all languages. Read its implementation.
Definition
Section titled “Definition”Require evidence naming the intended boundary before judging it. Separately establish use
of public entries, repeated internal bypasses, coordinated changes, and a deliberate bridge
role. Missing intent produces uncertainty rather than a guessed architecture violation.
boundary_depth selects how many module path segments identify each component.
Evidence
Section titled “Evidence”Findings cite the compact graph nodes, declared boundary, consumers, and representative changes that establish or contradict the crossing.
Exceptions
Section titled “Exceptions”Adapters, facades, gateways, and composition roots may intentionally cross boundaries.
Examples
Section titled “Examples”Three feature packages calling private storage implementation classes behind a repository
interface are leaky. One HTTP adapter translating into that same interface is an
intentional_bridge. Consumers reaching the storage package only through its public entries
are aligned, and a boundary no evidence names at all is uncertain.
References
Section titled “References”- Cites “Clean Architecture”, boundary anatomy
- Cites “Domain-Driven Design”, bounded contexts and anticorruption layers
- Cites “Building Evolutionary Architectures”, dependency fitness functions