Show me the backbone

The problem

You have just joined a project, or inherited a codebase you have never seen before. Someone tells you to "get familiar with the architecture." You open the project in the IDE and stare at 80 packages arranged in no particular order. You could start reading code at random. Or you could find the packages the rest of the system leans on and work outward from there.

Why it matters

Backbone packages have high fan-in: many other packages depend on them. That gives their public contracts the widest consumer blast radius in the current scope. A developer who knows the backbone knows which foundations deserve careful review before a contract change and which callers may need to move with it.

Where to start

Begin with the Topology Graph.

Step by step

1. Open the Topology Graph.

   Switch to the Topology Graph. Directed edges show which visible packages depend on which, while expansion controls let you choose how much package detail to reveal.

2. Choose whole-project or module scope deliberately.

   Start at the whole-project module overview, or right-click one module root and choose Set as Root before launching the workflow. Workflow presets preserve that Root, so a module-level backbone audit does not jump back to the whole project.

3. Apply the backbone starting point.

   Start exploring applies the upper-quartile Fan-in threshold, enables Hide Isolated, and activates the Fan-in heatmap. The darkest surviving packages have the most incoming dependents. A sparse model still requires at least one caller, so packages nobody depends on cannot become backbone candidates.

4. Reveal only the detail you need.

   Use Collapse All for the module overview. Choose Expand completely on one module when you need its package-level backbone. Expanding every module at once only makes the candidate set harder to read.

5. Inspect the callers behind the colour.

   Select a dark package and inspect its incoming neighbours and concrete dependency evidence. Those callers create its consumer blast radius. A package with high fan-out may coordinate many dependencies, but that alone does not make it part of the backbone.

6. Read the supporting metrics in context.

   Instability tells you whether outgoing dependencies also dominate the package's total coupling; it does not tell you how often the package changes. When Abstractness is available, use it as a separate public-surface check. A concrete backbone can justify a dedicated Zone of Pain investigation without becoming a placement verdict.

7. Remove a known visual distraction when necessary.

   If a generated or test package subtree distorts the read, choose Hide this package from view. This leaves metrics and cycle findings based on the complete in-scope analysis, and the module-aware rule does not hide a namesake in another module.

Interpreting results

High fan-in establishes backbone status, not a universal health verdict. Shared contracts, domain foundations, and intentionally reusable infrastructure often belong here. The important question is whether the package's responsibility and public boundary justify how many callers lean on it.

This is where a small contract mistake can become a broad migration. Inspect the incoming evidence before changing the surface, keep the responsibility legible, and protect important caller paths with tests. If the same package is highly concrete or coordinates many outgoing dependencies, follow that separate signal into Zone of Pain, boundary, or orchestration analysis.

Export & share

Use Export → Snapshot as PNG with the Fan-in heatmap active to capture the Topology backbone for an architecture review or onboarding document. The colours reflect the actual Fan-in distribution, so the backbone stands out immediately even without labels.