I bet on this as the major infrastructure component for software within near future.
Separation of Concern (SoC) is really important to me and goes beyond simple separation of layers os a software implementation. I should add “cohesive”, but this is part of the same idea: everythings doing the right thing in the rigth area.
This principle does apply obviously to the source code as a programming practice, useing a tool as maven that introduce some structure into the code organization. But it also apply to the architecture (SCA), the deliverables (DLL…and its hell), platform (OSGi / Spring DM server), components/framework (IoC, MEF), and methodologies (Agile).
The last one could be amazing, but I think the rational is the same: change adpoption. Kevlin Henney in his post Manage component dependencies for improved system quality says:
Another consideration in managing dependencies is the question of change. The dependency structure of a system can enable or discourage change, which makes dependency management a question of architecture, not merely one of fine-grained code quality
Having a system allowing effective depedency management at compile-time will ease test infrastructure setup (abaility to test a piece of code without having the entire system setup), hence quality…humm…be sure to automate your test to really ensure quality (doing manual repetive stuff is the best way to do it in a bad way over the time).
Having a system allowing effective depedency management at run-time will ease deployement as you will be able to do hotswapping of components even when they are running as for OSGi platforms.
Having a system allowing effective depedency management at run-time with version management, will allow multi-tenant applications and smooth upgrade…and probably start to solve the DLL’s hell.
