In the vibrant universe of software development, some topics, like true classics, always ignite passionate debate. We’re talking about those eternal discussions that divide the community: tabs or spaces? vi or emacs? Similarly, frameworks hold a privileged spot on this list of “things that stir up passions.”
Just like other fundamental tools (programming languages or text editors), frameworks leave no one indifferent. And for good reason, because they undeniably have a beneficial side.
The Friendly Face of Frameworks
There’s no denying that frameworks are an unquestionable help. When used correctly, they are a powerful tool that allows us to elevate the quality of the final product. Why? Because they offer us the opportunity to reuse common logic that has already been tested and polished. This translates into fewer errors and more efficient development.
Additionally, frameworks are excellent for establishing a guide, a way of working that promotes a common language among all users. They create a true ecosystem, acting as magnets that attract other developments and contributions, thus enriching the whole.
When the Framework Becomes a Problem
But like in any good story, there’s a turning point. The problem arises when the framework becomes the absolute center of our development, conditioning and ultimately negatively impacting our project.
Let me illustrate with an example. The vast majority of modern web frameworks (I’m thinking of Spring Boot, Django, or Laravel, with which I’ve had the pleasure of working) come with an integrated ORM (Object-Relational Mapping).
Often, ORM entities are used directly as domain models. For relatively simple CRUD (Create, Read, Update, Delete) projects, this can be a perfectly valid solution, even the best option. No need to be dogmatic. However, when we delve into more complex business domains, this practice often becomes a real liability.
Let’s see why:
- Rigidity in Domain Modeling When ORM entities are used as domain models, especially in projects with complex business logic, design freedom is diminished. Instead of using Plain Old Java Objects (POJOs) or similar plain classes that offer total flexibility to model the domain as best suits business needs, the developer is limited by the ORM’s restrictions and expectations. This can lead to a suboptimal design that prioritizes framework convenience over the true nature of the business.
- Difficulty Adapting to Changes or Evolving If our business logic is tightly intertwined with specific framework functionalities (like an ORM), any attempt to switch to another technology or even to update the framework to a major version can become a real nightmare. Every modification in the framework could demand significant changes in our domain code, which increases maintenance time and cost.
- Increased Complexity for Unit Tests The coupling between our domain models and the ORM makes unit testing pure business logic difficult. Often, it’s necessary to mock or initialize parts of the ORM for tests to work, rather than being able to test our domain classes in isolation. This not only slows down the development cycle but can also compromise the reliability of the tests.
- Excessive Framework Dependency Making the framework the “center” of our development makes us overly dependent on its design decisions and features. If the framework stops receiving support, or if a key functionality is removed or drastically modified, our project can find itself in a very complicated situation. Lower coupling would allow for a much simpler framework change or migration if necessary.
In summary, the main disadvantage lies in the loss of flexibility and control over our own business code. We are forced to adapt to the framework’s way of working, rather than designing a solution that is truly efficient and adaptable to the specific needs of our domain. Remember, the framework is just a detail.
