Dashboard

Architecture Graph

Interactive D3 force-directed graph visualization of module dependencies and architecture violations. Zoom, pan, filter, and inspect violations visually.

Architecture Graph

The Architecture Graph is an interactive visualization of your project's module dependencies, rendered as a D3 force-directed graph. It makes architecture violations visible at a glance --- you can see which modules depend on each other, where circular dependencies exist, and which boundaries are being violated.

Availability: The Architecture Graph is available starting in V1.5. Requires the Pro plan.

What the Graph Shows

Each node represents a module in your project (as defined by your radar.yml or detected by radar init). Each edge represents a dependency between modules --- one module imports from another.

The graph layout is computed using D3's force simulation, which positions strongly connected modules closer together and pushes weakly connected modules apart. The result is an organic layout that reveals the natural clustering of your architecture.

Reading the Graph

Node Colors

Nodes are color-coded by their violation status:

ColorMeaning
GreenClean --- no architecture violations in this module
YellowWarnings --- non-blocking architecture issues detected
RedViolations --- critical architecture violations that block merges

Node Size

Node diameter scales with the number of files in the module. Larger modules appear as larger circles, giving you an immediate sense of relative module size.

Edge Colors

Edges are colored by the type of relationship:

ColorRelationship
GrayNormal import --- one module imports from another within allowed boundaries
OrangeWarning --- the import crosses a soft boundary or follows a discouraged pattern
Red (dashed)Violation --- the import violates a layer boundary, module boundary, or creates a circular dependency

Edge Direction

Edges have arrowheads showing the direction of the dependency. An arrow from module A to module B means "A imports from B." This directionality is critical for understanding which module is the dependent and which is the dependency.

Interaction Controls

Zoom and Pan

  • Scroll wheel to zoom in and out
  • Click and drag on the background to pan
  • Double-click on the background to reset the view to fit all nodes

Node Interaction

  • Hover over a node to highlight it and all its direct connections. Non-connected nodes fade to 20% opacity, making the selected module's dependency neighborhood immediately clear.
  • Click a node to select it and open the Graph Sidebar with detailed information about that module.
  • Drag a node to reposition it. The force simulation adjusts other nodes accordingly. Release the node to let it settle into its new position.

Filter Controls

A filter bar at the top of the graph provides:

  • Category filter --- show only edges that represent architecture violations, or show all edges
  • Module search --- type a module name to highlight it in the graph and center the view on it
  • Severity filter --- show only modules with critical violations, warnings, or all modules
  • Hide clean modules --- toggle to remove modules with zero violations, reducing visual noise on large projects

Graph Sidebar

When you click a node, the Graph Sidebar slides in from the right with detailed information:

Module Summary

  • Module name and file count
  • Current violation count (critical / warning / info)
  • List of layers the module spans (e.g., "domain, application")

Violations List

Each violation in the selected module is listed with:

  • Rule ID (e.g., layer-boundary-violation, circular-dependency)
  • File path and line number of the offending import
  • Description of what the violation means
  • Severity badge (Critical, Warning, Info)

Click any violation to navigate to the full violation detail in the Violations page.

Dependencies

Two lists:

  • Imports from --- modules this module depends on, with edge color indicators
  • Imported by --- modules that depend on this module

Common Patterns to Look For

Circular Dependencies

Circular dependencies appear as red dashed edges forming a loop. Two or more modules with red dashed edges pointing at each other indicate a cycle detected by Tarjan's algorithm.

In a healthy architecture, the graph should be a DAG (directed acyclic graph). Cycles indicate modules that are tightly coupled and difficult to change independently.

Layer Violations

A red dashed edge from a domain module to an infrastructure module indicates a layer boundary violation. In DDD and Clean Architecture presets, the domain layer should never import from infrastructure.

Look for red edges that cross from inner layers (domain, application) to outer layers (infrastructure, API). These violate the dependency rule.

Hub Modules

If a single node has many edges radiating from it, that module is a hub --- many other modules depend on it. Hub modules are high-risk because changes to them ripple across the codebase. The node's size and connection count together tell you whether a module is both large and heavily depended upon.

Isolated Modules

Nodes with no edges may indicate dead code or modules that are not yet integrated. While not a violation, isolated modules in a production codebase warrant investigation.

Performance

The force-directed simulation runs in the browser using D3. Performance characteristics:

Project SizeNodesEdgesRendering
Small (5--15 modules)InstantInstantSmooth at 60fps
Medium (15--50 modules)Instant< 1 secondSmooth
Large (50--150 modules)< 2 seconds< 3 secondsMinor jank during initial layout
Very large (150+ modules)Use filtersUse filtersFilter to subsets for usability

Tip: For very large projects, use the severity filter to show only modules with violations. This reduces the node count to a manageable subset while keeping the most important information visible.

Example: Reading a NestJS Feature-Module Graph

In a NestJS project using the feature-module architecture preset:

  1. Each feature module (Orders, Users, Auth, Products) appears as a node
  2. Shared modules (Database, Config, Logger) appear as smaller utility nodes
  3. Normal module imports through *.module.ts show as gray edges
  4. A direct service-to-service import across modules (e.g., OrderService importing UserService directly instead of through the Users module) shows as a red dashed edge
  5. Clicking the red edge's source node opens the sidebar showing the module-boundary-violation with the exact file and import statement

This visual representation makes it immediately obvious where the architecture is clean and where boundaries are being violated.

Technical Debt Radar Documentation