Cyclic dependencies

Also known as: strongly connected components (SCCs) · dependency cycles · circular dependencies

What it is

A dependency cycle is a strongly connected group of in-scope architecture units: every member can reach every other through dependency paths. AtlasArc preserves that structural cycle as evidence, but reports active warnings from a separate problem graph. Precise Intentional or Debt governance and local Safe Havens can break the warning graph while the underlying dependencies remain available for inspection.

Screenshot: Topology with the Cycles sidebar open, Show cycles only enabled, classification badges visible, and one active problem-cycle group selected
The structural dependencies remain inspectable while the Cycles surface concentrates the unresolved problem graph.

Why it matters

Imagine you want to pull your domain layer into a shared library. Clean idea. You start extracting it and then discover it imports from your persistence layer. The persistence layer imports from your service layer. The service layer imports from domain. The extraction that was supposed to take a day now touches half the codebase, and you haven't written a single line of new code yet. That's what unchecked cycles cost. They don't cause problems the day someone adds the import. They cause problems the day you try to move anything.

What a high value usually means

Cycle-group count shows how many unresolved groups are represented. In subsystem rollups, largest-cycle size shows how many architecture units belong to the widest contained group. Many small loops and one broad tangle are different refactoring problems, so read the two values together rather than treating either as a universal severity score.

What a low value usually means

Zero means no cycle remains in the current problem graph for the current repository-scoped evidence. It does not prove clean layering, independent deployment, or the absence of governed structural cycles.

When not to overinterpret it

Cycle status distinguishes active Architectural cycles, Aggregation effects at a collapsed resolution, Nested-internal cycles, governed or locally suppressed structural evidence, and no current cycle. These states help you separate an architectural warning from hierarchy context or a decision already made. A cycle count of three in a project of 200 architecture units is also not the same problem as three in a project of twenty: inspect the boundaries, group size, dependency evidence, and intent before deciding what to change.

Where AtlasArc shows it

Cycle styling appears in compatible lenses without requiring Cycles Only. The Cycles sidebar lists detected groups and their classifications; Show cycles only enables progressively narrower detail levels, group navigation, and entry into a selected Cycle View. Subsystem metrics include contained cycle-group count and largest contained cycle size.

How AtlasArc computes it

AtlasArc applies repository Analysis Scope before cycle evaluation. It preserves the resulting dependencies in the structural graph, then removes dependencies covered by precise governance or local Safe Havens from the warning calculation. Strongly connected components in that problem graph form reported cycle groups. Group count is the number of those groups, largest-cycle size is the greatest member count in a contained group, and cycle depth is the shortest loop within a group.