Fan-in and fan-out
Also known as: afferent coupling (Ca) · efferent coupling (Ce)
What it is
Every architecture unit has two numbers that turn out to be surprisingly informative. Fan-in is how many other units depend on it. Fan-out is how many other units it depends on. High fan-in means a lot of the architecture is counting on you. High fan-out means you're counting on a lot of the architecture. AtlasArc keeps the number of underlying dependency references separate: fan-in and fan-out describe how many neighbours are connected, while reference count shows how heavily each connection is used.
Why it matters
Think about what it means to change a package with fan-in of 40. The edit happens in one package, but the risk reaches 40 others. You need to check them, update them, retest them. That one-line fix you thought would take an hour is now a Tuesday afternoon. Fan-in and fan-out don't tell you whether a change is safe, but they tell you how far the blast radius reaches before you make it.
What a high value usually means
High fan-in means many packages depend on this one. That's natural for shared utilities, core domain types, and stable framework libraries. It also means any API change is expensive and needs to be considered carefully. High fan-out means this package imports many others. Above a certain threshold it starts to look like a god package that has taken on too many concerns, or an adapter that has grown well beyond its original purpose.
What a low value usually means
Low fan-in means few packages depend on this one. That's expected for leaf packages like adapters and application bootstrapping. For shared utilities, low fan-in might mean the abstraction isn't being used and is worth questioning. Low fan-out means the package is self-contained, which is a natural and desirable trait for utility packages, domain primitives, and stable interfaces.
When not to overinterpret it
High fan-in is not inherently bad. A well-designed API or domain model should have high fan-in, because that's the point of an abstraction. High fan-out isn't inherently bad either, for an adapter or bootstrap layer whose job is to wire things together. Read fan-in and fan-out alongside instability and the package's architectural role before drawing conclusions. A package with high fan-out and high instability is a different kind of problem than one with high fan-out and low instability.
Where AtlasArc shows it
In the sidebar when an architecture unit is selected in the Topology Graph or Package Matrix. Open either metric to see the coupled units and the reference count carried by each relationship; select a dependency to inspect its route and available source examples. Fan-in and fan-out also appear as left-sidebar filters, as axis options in Subsystems and Hotspots, and in exported Subsystems and Hotspots data.
How AtlasArc computes it
Fan-in (Ca) = number of other architecture units with an incoming dependency on this unit. Fan-out (Ce) = number of other architecture units this unit has an outgoing dependency on. The reference count on each edge is the separate total of underlying dependency references; it does not increase fan-in or fan-out unless it introduces another coupled unit.