Find technical debt at dependency-injection boundaries

Dependency-injection code is often treated as plumbing. It is also a compact map of architecture decisions. Review it for debt signals before adding another binding.

Signals worth investigating

An oversized application module usually means feature boundaries are not explicit. String qualifiers can hide a missing type. Definitions that open databases or start jobs during graph creation mix construction with behavior. A process-scoped object that accepts a screen-owned dependency indicates lifetime inversion.

Other useful signals include:

• a long list of framework exceptions in graph verification;
• tests that must start the complete production container;
• platform types exposed to common code;
• runtime parameters passed through many unrelated definitions; and
• modules loaded and unloaded from several UI locations.

These are investigation prompts, not automatic defects. Record the real ownership rule before changing the container.

Pay debt at a boundary

Choose a product slice and define its public inputs, outputs, and lifetime. Move its definitions into a small module. Replace string qualifiers with typed distinctions where the language and framework support them. Separate resource construction from starting work. Add a graph test for the slice and a behavior test for its owner exit.

Do not reorganize every definition as one migration. A boundary-sized change gives the team a rollback and shows whether the new structure improves errors, tests, and ownership discussions.

Measure the result

Useful measures include startup work, verification time, number of definitions in a slice, number of cross-feature edges, and the amount of setup required by a test. The aim is not the smallest module count. The aim is a graph that explains the application and fails near the defect.