Sensor family 08
Architecture
“Is the system becoming harder to reason about?”
What belongs here
These sensors measure the shape of the system rather than its behaviour — how the parts depend on each other, and how expensive it is becoming to reason about them. None of them can tell you the system is wrong; they tell you it is getting harder to know.
Contested placements
Live Service Graph Discovery observes production traffic, which makes it a runtime sensor whose subject happens to be architecture. Everything here has a weak oracle: high coupling is a smell, not a defect.
Where its signals arrive
- Static analysis / types — Build stage. Is it internally coherent and structurally valid?
The atlas places every family on the same lifecycle grid; the framework defines the six dimensions each entry below is characterized along.
Entries (5)
Boundary Sensors
“This package must not import that package.” A sensor of encapsulation and module boundaries — computationally enforced, not prose rules.
Dependency Graph
Fan-in, fan-out, cycles, dependency depth, unstable dependencies. A sensor of structural coupling between modules.
Architecture Fitness Functions
frontend -> application -> domain -> infrastructure, and fail if domain -> infrastructure. A sensor of architectural drift.
Hotspot Analysis
Change frequency times complexity. Identifies places where the system is simultaneously difficult and frequently changed — more interesting than “files with the most lines.” Hotspot analysis combines…
Live Service Graph Discovery
The declared architecture says service A never calls service C. The live service graph — discovered from actual traffic via a service mesh, eBPF flow mapping, or trace aggregation — says whether that…
Adjacent families
- Previous: Change — What did this change actually affect?
- Next: Evolution — Does this look like changes that caused trouble before?
- All of them: the complete catalog (this family is also anchored there at /catalog/#architecture).