Pattern · seen in 1 breakdown across 1 company
Compile-Time Boundary Enforcement
Definition
Declare an architectural boundary as data, then enforce it with automated checks that fail the build — or flag the violation in development — whenever code crosses it. The boundary becomes real the day it is declared, not the day the underlying systems are actually separated: developers hit violations at their desks, CI blocks new coupling from landing, and existing violations are converted into an explicit, annotated backlog that must reach zero before the physical separation can proceed.
The pattern's power is temporal. Long-running migrations — splitting a database, extracting a service, partitioning a module — take months or years, and during that window the codebase keeps changing under the migration's feet. Enforcement at development time freezes the boundary's erosion: the migration can only move forward, because regressions are build failures rather than operational surprises discovered after data has moved.
Static checks cannot see everything — dynamically constructed queries, runtime reflection, and cross-cutting transactions evade them — so mature implementations pair the compile-time check with a sampled runtime check in production that maps where the boundary is actually crossed, feeding the burndown list.
When it applies
Tradeoffs
The same move, 1 ways
Every row is a production system that bet on this pattern — the note says how, in that system's own terms.
Problems this pattern answers
The walls where its breakdowns live — each opens the cross-company comparison.