Modifications to model and relational database

Asked

Viewed 142 times

4

The requirements for the development of 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.

Moreover, 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 use the developed system they also happen to recognize points that need to be modified, because there was some requirement that was forgotten or that was not well understood. In fact, from what I have read there are approaches that encourage the software to be developed by parts and as already have working parts users already have access to validate what has been done and provide this feedback.

So far so good. The biggest problem is the following: when the system is already being used there is a real production database containing the real data of the users. These data, considering relational databases, are table representations of the objects of the domain model.

Now, let’s assume that a modification is required in the domain model that removes some properties and/or places others. An example would be a datum 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’re using object orientation the right way. Of course, the bigger the system the more the modification can impact, but still it is something more manageable, as it can be worked entirely in the development environment.

On the other hand, when applying modifications of this type, the model is no longer synchronized with the bank. A new table structure would be required to accommodate the new data. And the fact that there’s user data that just can’t be thrown away and that they need to accommodate the new model is a huge headache.

In this case the relational database ends up blocking the improvement of the domain model.

My approach in some situations was to create a utility that turns the old database 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 database.

This approach, however, does not seem the most efficient.

So I ask you, how do you deal with this situation? How to work with the domain model freely and at the same time synchronize with the data in the production database?

database oop relational-model ddd
  • 3

    It has no magic: an iterative project, which embraces change and encourages Refactoring (Agile/DDD), requires that the bank can be changed with relative simplicity as well. Changing a relational bank will never be as easy as changing the code, but you have to pursue that facility. It’s nothing trivial, but it’s quite viable. I would describe one or two methods that you could use, but I think it would give an answer too long and these methods still depend on the technologies you use or tools you’re willing to use.

  • I even thought about some cases of using Nosql but until today I could not study very deeply the different types of Nosql databases and the situations in which it is worth using. Could you tell me where I can see some methods that can be used to solve this problem?

  • The relational model is excellent for its accuracy in the domain representation, since you are aware of it during construction, however it "pure" is really resistant to change. Since you are considering Nosql know before that this is a comprehensive term that refers to any type of database that "is not sql" then there is a plethora of models: dbs of graphs, dbocument oriented, Object oriented dbs, etc. Often a given representation is superior/more flexible in a certain case, for example social networks are natural graphs, but it depends on the case.

  • 1

    I started to write an answer but the time is over and, already huge although very short, it is not even 30%! If I can finish another day, I’ll put it here. See these articles: http://martinfowler.com/books/refactoringDatabases.html and http://martinfowler.com/articles/evodb.html. See also my comment on a colleague’s blog: http://www.rafaelleonhardt.com.br/2012/01/12/datatier-applications-x-code-first-Migrations/. Do not be alarmed: it is feasible to use iterative approach also in the relational database! I’ve done enough of this, successfully. It takes a lot of automation but it’s worth it.

1 answer

1

Your concern in not to let there be a great distance between the relational data model and the domain model is really important, but we have to Domain Model:

  • Contains knowledge about a problem/knowledge, fruit collaboration between business experts and development;
  • Enables the developer to communicate with business experts in a natural language;
  • It is linked to the implementation of your code and not to your database.

Quote: I found in the book the following excerpt...

Technically, the design of relational tables does not have to reflect the domain model. Mapping tools are sophisticated enough to handle significant rights.

That is, the DDD does not say to keep your domain model or your business object synchronized with the database, It would be great if your business object were synchronized with your BD, but, not always this is possible, not always you are developing the bank as you develop your code. On the contrary, there are cases that this synchronization is really not possible, such as a BD that was created for another system for example.

So, thinking of a case where you have a field in the relational BD and you for some reason need to keep it, but that field no longer exists in your object due to a new requested change, an interesting alternative is to stop mapping the field, thus, when consulting the BD record corresponding to the object, the field would no longer be recovered, it would be as if the field even existed in the BD.

  • On the same page of the book where you find this quote, you also find Eric Evans pondering that if the foundation is designed for a particular model, it is important to keep them close even at the expense of some sacrifice in the model or some sacrifice in normalization. Despite the capabilities of the ORM, keeping the mapping simple and readable is also very important. The book would be bad if it said "worry only about the domain and little about the database" because this is not our reality in software development, right?

  • "When the base is seen as a repository of objects, don’t let the base model and object model diverge too much, despite the powers of the Orms. Sacrifice some richness of object relationships to keep them close to the relational model. Compromise some formal relational base patterns, such as normalization, if this helps simplify object mapping." - Eric Evans in his book DDD.

  • And where did I say this isn’t important @Caffé ???? Read the first sentence of the answer there man! " Your concern in not to let there be a great distance between the relational data model and the domain model is really important" I’ll even put in bold rs. Please come back with my dots because if you didn’t read it or understand it differently than it is written was your misinterpretation.

  • Well, the vote is precisely according to the interpretation of who votes, right? Don’t worry, there will be more positive votes in your reply. In my humble opinion, she doesn’t answer the question. It merely conforms to the difficulties of keeping the base up to date as the model is updated.

  • @Caffé finds his attitude very strange, it is very clear in the answer and in bold that it is important to keep domain and relational model close, but this is not always possible and an alternative has been suggested. I find a useful answer yes, based on the book and I find your attitude very strange, the purpose here is to help. Whether it fully answers the question or not is defined by who is asking, who is to mark the final answer that meets what he was in need of. Your interpretation was mistaken, who will read.

Browser other questions tagged database oop relational-model ddd

You are not signed in. Login or sign up in order to post.