The database is not the center of your application.
Your use-cases are. The database is a dependency and should be treated as such.
Data is the blood of your application. It is pumped by the heart (the use case layer), to feed your organs (the drivers of your applications, often the users) from the blood-making organs (the driven parts of your application, often the database).
According to this metaphor, the database is not the center of the application. It is an essential part, just as all the other parts, but it is definitely not the center.
A story
Once upon a time, a team of developers embarked on a mission to create a cutting-edge application. This application was not just any ordinary software; it was envisioned to be the backbone of a major enterprise, handling critical operations. The team poured their heart and soul into using the latest database technology and then building a robust and sleek back-end system on top of it. They proudly employed the latest features of the ORM (Object-Relational Mapping) system, intricately linked to this latest, trendiest database in the tech world.
For weeks, the developers worked tirelessly, turning sweat into lines of code. Their dedication bore fruit, and the application was launched to great fanfare. It was a thing of beauty - fast, efficient, and seemingly flawless.
However, the euphoria was short-lived.
A few weeks post-launch, an unexpected announcement from the developers of the renowned ORM system sent shock-waves through the team. The ORM was undergoing a significant overhaul, one that would require adapting all 189 entities within the system to align with the new ORM update. The implications were staggering. This wasn’t just a minor tweak; it was a complete transformation that demanded a colossal effort.
The team was devastated. The months of hard work, the intricate coding, the meticulous optimizations – all seemed in jeopardy. The task ahead was daunting. Adapting the hundreds of entities was not only a monumental technical challenge but also a race against time. The integrity of data, the core of their application, was at risk.
Moreover, the ripple effects were far-reaching. Every change in the entities had a cascading effect on the business rules, the very rules that were the foundation of their application’s functionality. It was like a house of cards, ready to collapse with the slightest of changes.
The team plunged into the task, but the journey was riddled with hurdles. Each adaptation opened a Pandora’s box of issues – from data migration problems to unexpected bugs in the system. Days turned into weeks, and weeks into months. The once enthusiastic team was now a group of weary developers, burdened by the relentless demands of the ever-changing database dependencies.
This made-up story for the purpose of this article will revive difficult memories for the engineers reading this article. It serves as a cautionary tale. It underscores the perils of placing the database at the heart of an application. When the database is considered merely an implementation detail, and the core of the application is insulated from such dependencies, such nightmares can be avoided. This approach not only ensures portability, making it easier to switch between different database systems, but also enhances testability and maintenance, making the application more resilient and adaptable to change.
From the use-case perspective, whether you save your data in a relational DB, a file, a piece of RAM, should have no impact.
If we come back to the metaphor I wrote at the top of the article: the organs do not care from where the heart is pumping blood, as long as it is fresh, oxygenated blood. Same with your users, they don’t care from where the data comes, whether it’s this or that DB, as long as it is what they needed to perform their task.
Thus, the database should not be the foundation block of your application, the use-cases are.
From a software architecture perspective, removing the DB from the center allows:
- Portability: it will be obvious to switch from one DB system to another,
- Testability: it will be much easier to test business rules by being able to abstract the database in tests,
- Maintenance: the application is now much cheaper to maintain since it’s modular and testable.