Decoupling or Following the crowd?

The short version of what decoupling is may be: “Create independent deliverables in our systems to enable different team members to work fluidly on different parts of the system”

We find this recommendation often and it is an accepted new way to build big scalable projects.

However, we also are in an era where the frameworks we use to scaffold our system have difficulties applying this method. As a consequence, many projects are still built with a deeply coupled base and the consequence is often that we build coupled artifacts every day.

With the Magento framework that I have used for more than a decade, we have this problem when using the system with its original architecture. Using the newer possibilities that Magento has, it is possible to push the boundaries further and deliver more advanced layered works.

Although we’d want a change of the schema to have only some side-effects in one area of the system, we have today our systems built with a core that still supports a list of intertwined list of layered responsibilities.

Sometimes, our strength can become our weakness and it may be comparable with how we as a team consider our preferred framework. Because Magento excels at being extensible and this applies to layout, to style, to schema and finally to configuration, we are using a sophisticated web of combinations that can all move in different directions and by people with varied skills and awareness of their responsibilities.

No one wants to build a deliverable that is fragile and that is why scoping our features to make them do their customisation with a local approach is how we start our work in most situations.