the inversion of compile dag
Advocated by Robert Martin
In Software, there are mainly two dependency situations:
- Run Time => When program execution flow leaves from one module to another
- Compile Time => When a name from one module appears in another module.
Compile Time Dependencies are those that need to be taken care of. Because, a bad compile DAG may not only result in high compile time but also many number of deployments in production environments.
If Compile Flow goes similar to Run Time, like shown below:
As you can see run time and compile time dependencies are same.
Then for each change in low level module needs a recompile and redeploy in all high level modules that are coupled.
We can address this problem by inverting the dependencies in compile time. Like below.
If the dependency is inverted and all the modules in the lower bottom of the graph are made as plugins to the higher level. Then any changes in these lower level modules, need not need recompile of whole path.
This also enables independent deployability, developability.
In a good architecture, the Main should be a plugin to the rest of the application.
As the main code frequently changes, there should be fine boundary between main section and app section.
So in short, Inversion of source code dependency against the flow is called Dependency Inversion Principle.