The database is not the center of your application.

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.

Treat the database as a dependency that can be changed

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 easier maintain since it is testable in isolation.

So, here we are. Databases are just tools, and they belong in the background.

The moment you stop making the database the sun around which everything orbits, you gain the power to outpace the relentless evolution of tech stacks and ORM fads.

Real resilience in application design comes from centering your architecture around the real core: the use cases that actually drive value. A solid, adaptable application should function whether you’re storing data in PostgreSQL, a document store, or a text file. Data persistence is an implementation detail, not the soul of your system.

So, stop architecting applications like they’re database-bound castles made of sand. Start designing with use cases at the heart, because they’re what last. The database? It’s just the data bus, not the driver’s seat.