The Main Component

Let's locate ourselves in the branch: package_per_layer.

Here we have the Gradle module dependency and the component diagram of the package-by-layer project branch (Let's ignore the core module for the moment).

Gradle Modules Dependency	Component Diagram

Why is this dependency different from the component diagram? If in the end the app Gradle module ends up using software elements from the localData and remoteData modules, as shown in the code:

package com.vanskarner.cleanmovie.di; // Here we are in the app module
import com.vanskarner.localdata.LocalDataModule; // Here is a dependency
import com.vanskarner.remotedata.RemoteDataModule; // Here is a dependency

@Singleton
@Component(modules = {
        ProjectParametersModule.class,
        CoreModule.class,
        DomainModule.class,
        LocalDataModule.class, 
        RemoteDataModule.class,
        ViewModule.class
})
public interface AppComponent extends AndroidInjector<App> {

    @Component.Factory
    interface Factory {
        AppComponent create(@BindsInstance Context context);
    }

}

The answer is that the MAIN component is missing from the diagram.

Also, let's remember that the Gradle module dependencies don't always represent the dependencies in the components; they are different approaches.

Concept

The Main Component is responsible for setting up initial conditions and configurations, gathering all external resources, and then handing control over to the high-level policy of the application.

Content

This component is composed of all the factories, strategies, global installations, and dependency injection frameworks used in the project. Therefore, the modules and the generated code are this component in action. Another point to consider is that they are not only found in the production code, but also in the test code.

Dependency injection frameworks	Core	Domain

RemoteData	LocalData	App

It is valid to have multiple Main Components, one for each application configuration, such as for development, production, and testing. It is even possible to have one for each country, jurisdiction, or customer.

Conclusion

When considering Main as a plug-in component that lies behind an architectural boundary, the configuration problem becomes more manageable.