Architecture patterns / Architectural Gravity
Draft
Gravity-center exemplar pending — needs dedicated proof block from repository analysis.
What is architectural gravity?
Architectural gravity is the tendency of dependencies to accumulate around a few central modules — orchestrators, shared utilities, or type authorities — that coordinate many subsystems.
Trust path: Homepage → Validation → Repository proof → Architectural Gravity → Install
Why it matters
Gravity centers are where refactors stall and incidents cluster. They are not always mistakes: frameworks need gravity. The question is whether you know which modules pull the graph toward them before you change them.
What it looks like in codebases
- One config module referenced by server bootstrap, client hydration, and build tooling.
- Shared utility hubs that become the default import for new features.
- Renderer or data layers that every feature route touches transitively.
Real repository example
No indexed exemplar yet. See Next.js repository proof for the current flagship analysis while this pattern page is in draft.
How ArcSight detects it
- Gravity-center fields in arc structural output (role + module).
- High betweenness on impact paths — few modules sit on many routes.
- Hotspots with large blast radius despite moderate fan-in.
$ arc hotspots# Centrality ranking
What to inspect first
- Modules labeled as gravity centers or orchestrators in analysis output.
- Whether new features add edges to the same hub instead of local boundaries.
- Subsystem maps: does one module bridge unrelated folders?
What to do next
- Document intentional gravity — which hubs are product architecture vs drift.
- Run impact before adding another import to a gravity center.
- Split orchestration from pure types when gravity slows releases.
Run ArcSight on your codebase
Install locally, run arc impact on the module you plan to change, and get structured evidence — before you merge.
npm install -g arcsightInstall →