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:
| Color | Meaning |
|---|---|
| Green | Clean --- no architecture violations in this module |
| Yellow | Warnings --- non-blocking architecture issues detected |
| Red | Violations --- 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:
| Color | Relationship |
|---|---|
| Gray | Normal import --- one module imports from another within allowed boundaries |
| Orange | Warning --- 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 Size | Nodes | Edges | Rendering |
|---|---|---|---|
| Small (5--15 modules) | Instant | Instant | Smooth at 60fps |
| Medium (15--50 modules) | Instant | < 1 second | Smooth |
| Large (50--150 modules) | < 2 seconds | < 3 seconds | Minor jank during initial layout |
| Very large (150+ modules) | Use filters | Use filters | Filter 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:
- Each feature module (Orders, Users, Auth, Products) appears as a node
- Shared modules (Database, Config, Logger) appear as smaller utility nodes
- Normal module imports through
*.module.tsshow as gray edges - A direct service-to-service import across modules (e.g.,
OrderServiceimportingUserServicedirectly instead of through the Users module) shows as a red dashed edge - Clicking the red edge's source node opens the sidebar showing the
module-boundary-violationwith the exact file and import statement
This visual representation makes it immediately obvious where the architecture is clean and where boundaries are being violated.