One of the goals of modular frameworks like Kohana or Alloy is to make it easy to add and remove components (i.e. "plugins" or "modules").
However, in all the larger projects I have ever worked – the system often becomes dependent on the modules it is built on. After all, that is why they are there – to build with them.
So, I'm wondering if the concept of building distinct separate sections of a web application as independent modules is even a good idea to begin with? For example, we may build a general user, forum, and blog module – but each project is different and usually involves building many layers of abstractions to add new features – or editing the files directly to customize them. I can't re-use the same module on multiple projects.
In other words, they are no longer just a plug-in-play add-on to the site.
Now I'm not confusing this with proper class design to ensure un-coupled MVC and library logic. But I'm wondering if "MMVC" was a superfluous effort to apply proper class design concepts to application design as well. After all, many migration systems or database libraries like Doctrine require all the relations spelled out in the models from day one, thereby linking the entities.
Is it one of those things that sounds like a good idea when the project starts, but eventually is shown to be a useless feature? Do modules have their place in systems like wordpress – but not in frameworks where you are obviously building something custom?
Best Answer
The purpose of modules and frameworks is not so much to achieve independence of functions as it is to achieve reusability and flexibility. In most other occupations, this kind of reuse of function and flexibility is central to achieving success.
Think about how difficult it would be to work on your car if you had to buy a whole new tool set for each car, because the tools were not interchangeable. Or worse, you hae to build the tools from scratch, because there wasn't a factory to create them. Both of these concepts (universal pluggability and object factories) are present in well-written modules and frameworks.
You are describing tight coupling, an undesirable trait of software that's intended to be reused. Properly written libraries, frameworks and modules achieve loose coupling through software patterns such as Inversion of Control, message passing, and universally-understood communication methods such as REST and XML. These are not the only methods by which loose coupling can be achieved.
Obviously, it is impossible to write a completely decoupled system; one part of the system has to know something about the other part of the system, or nothing gets accomplished. But a high degree of decoupling can be achieved nevertheless.
Writing modular software takes more work and forethought than writing tightly-coupled systems, but the effort can be worth it, especially when writing a framework or library that will be used by many people.