How can I understand a heavily decoupled C# system wired together with dependency injection?

I usually begin by learning the small part of the DI library that the application actually uses, then find the project’s registration conventions. Wiring may be centralized in one module or distributed across feature-specific setup files.

After that, I run the application under a debugger and inspect the resolved services. Some codebases also have registration diagnostics or a startup dump that lists the container contents. Combining that information with breakpoints gives you a concrete map instead of relying only on IDE navigation.

A sequence diagram or a simple hand-drawn flowchart can help a lot. Pick one event and document where it originates, which publisher emits it, which handlers receive it, and which pipeline processes it. You don’t need to diagram all 50 pipelines at once—trace one complete path, then use it as a template for the others.

This architecture can be useful when components need to be loaded or replaced independently, such as plugin or regulated algorithm systems. The tradeoff is that the wiring is moved from ordinary code references into configuration and container registration, so the runtime behavior is harder to discover.

It’s worth remembering that the difficulty you’re having is a real cost of this design, not simply a failure to understand it. Dependency injection and open generics reduce coupling, but they also hide construction and call relationships from static tools. Keep a small map of registrations, resolved concrete types, and event flow as you investigate. If the codebase has maintainers, ask whether there is an established registration convention or a diagnostic mode; teams sometimes have tools for dumping the container configuration.

Start with the Autofac registration code rather than searching for references to each concrete class. Look for assembly scanning or bulk registration calls that register implementations of Pipeline, Handler, or similar interfaces. That will tell you which assemblies are involved and which concrete types are available to the container.

For the runtime path, put a breakpoint in the generic interface method or in the common base class, then trigger a real event. The call stack will show the concrete implementation Autofac selected and how the event moved through the system. This is often much faster than trying to infer everything from static references.