In every system, there is at least one component that creates, coordinates, and oversees the others.
The Main
component is the ultimate detail, the lowest-level policy. It is the initial entry point of the system. It's job is to create everything needed and then hand control over to the high-level abstract portions of the system.
It is in this Main
component that dependencies should be injected by a Dependency Injection framework. Main
should distribute those dependencies normally, without using the framework.
Think of
Main
as the dirtiest of all the dirty components.Main
is a dirty low-level module in the outermost circle of the clean architecture.
Think of Main
as a plugin that sets up initial conditions and configurations, gathers all the outside resources and then hands control over to the high-level policy of the application. Since it is a plugin, it is possible to have many Main
components, one for each configuration of your application.
For example, you could have a
Main
plugin for Dev, another for Test, and yet another for Production. You could also have one for each country you deploy to, or each jurisdiction, or each cvustomer.
When you thing about Main
as a plugin component, sitting behind an architectural boundary, the problem of configuration becomes a lot easier to solve.