The requirements for developing a system in general change over time. Several approaches to software development such as agile methods and Domain-Driven Design even encourage an iterative approach in which we delve into the real needs of a system over time.
In addition, when building any system it is very important to know the domain of the problem being solved and, in this case, this knowledge deepens over time.
As end users are using the developed system it also happens that they recognize points that need to be modified because there are some requirements that have been forgotten or not well understood. In fact, from what I've already read there are approaches that encourage the software to be developed by parties and that as they already have working parts users already have access to validate what was done and provide that feedback.So far so good. The bigger problem is this: when the system is already being used there is a real production database containing the actual data of the users. These data, considering relational databases, are table representations of domain model objects.
Now, let's assume that a modification is required in the domain model that strips some properties and / or places others. An example would be a data that is currently represented in a single property, but will be represented in several, or some data that did not exist before and was placed.
Modifying the domain model is relatively easy, especially if we are using object orientation the right way. Of course, the larger the system, the more modification can have an impact, but it is still more treatable because it can be fully worked on in the development environment.
On the other hand, when applying such modifications, the template is no longer synchronized with the database. A new table structure would be needed to accommodate the new data. And the fact that there are user data that simply can not be thrown away and need to accommodate the new model is a huge headache.
In this case, the relational database ends up hampering domain model improvement.
My approach in some situations was to create a utility that transforms the old bank into the new one: we implemented mapping classes that take an object from the old model and return one from the new model. From there we make a utility that runs through the production database converts the objects and persists in a new bank.
This approach, however, does not seem to be the most efficient.
So I ask: how to deal with this situation? How can I work with the domain model freely and at the same time synchronize with the data in the production database?