Find packages that know too much

The problem

One package seems to know about everything. It calls services, repositories, clients, mappers, and utilities across the codebase, while very little depends on it in return. That may be exactly what an application coordinator or adapter is supposed to do. It may also mean several unrelated responsibilities have collected in one place. You need the outgoing evidence before deciding which.

Why it matters

Every outgoing dependency is another seam the package must coordinate and another place where an upstream change can reach it. A deliberate composition root can carry many such seams cleanly. A domain or utility package with the same shape may be hiding orchestration, integration, and business logic behind one name. Finding that difference early keeps the next change from spreading through a knot of collaborators.

Where to start

Begin with the Topology Graph.

Step by step

1. Apply the outward-responsibility starting point.

   Start exploring opens Topology, keeps packages at or above the model's upper-quartile Fan-out, keeps Fan-in at or below the median, and enables Hide Isolated. The surviving packages depend broadly outward while relatively few packages depend on them.

2. Scope one module when that is the real question.

   Right-click its first-class module root and choose Set as Root, then use Expand completely only there. The preset remains active while unrelated module detail stays out of the way.

3. Inspect the outgoing evidence.

   Select a surviving package and follow its outgoing neighbours. Open the concrete dependency evidence behind each important edge so you can see which classes create the seam and whether several edges serve the same responsibility.

4. Name the package's intended job.

   Coordinators, adapters, and composition roots legitimately connect many areas. For an ordinary domain, utility, or feature package, ask whether every outgoing dependency belongs to the responsibility its name promises.

5. Preserve the role or reduce the spread.

   Keep a deliberate coordinator and protect its integration seams with tests. Otherwise remove unused dependencies, split unrelated responsibilities, or place a narrow adapter around an external concern.

Interpreting results

High Fan-out and low Fan-in identify a structural role, not an automatic violation. The package reaches across many dependency seams but is not itself a widely reused foundation. That makes it the right place to ask whether the outward knowledge is deliberate.

A clear application coordinator may be doing its job perfectly. A package whose name promises one domain responsibility but whose outgoing edges span persistence, transport, UI, and integration concerns is carrying a different shape. AtlasArc shows that shape and its concrete evidence; your intended architecture determines whether to preserve it or refactor it.

Export & share

Export the filtered Topology view as PNG to capture the shortlist and its outgoing routes for review. Open concrete dependency evidence in AtlasArc when the team needs to trace a route back to the responsible classes.