Summary

Most Blueriq applications need to read or store information which is filled in by the user. Only sandbox applications do not have interaction with a database. The database is located in the interface layer, while the business domain is in the domain layer. What we want to avoid is that the business domain needs changes because the database technology changes. If this is the case, then the model is coupled which reduces maintainability and agility as a change in the database leads to a mutation in the domain layer.

In this example we regard the case that a user filled in a simple application form, and the data now needs to be persisted by the company, so that it can be read later on.

Problem

A database is a piece of technology which provides the service of data storage to a Blueriq application. Technology is continuously changing, and next to developments within the world of relational databases, there also exist completely different technologies such as document-oriented databases or graph databases. These technologies all have different properties, and different manners in how the data is stored.

When storing information from within Blueriq in such a database, a translation has to be made to a format which is suitable for the database. What should be avoided is that this translation is done in the domain layer. If that is the case, then any change in database technology requires a change in the domain layer. It also imposes a structure in the domain layer, resulting in that you are not free to choose create a domain model in the best wat to describe the business. With this coupling the database structure has to be followed. Any change in the database results in a change in the domain model and vice versa. Ideally, a change in the database has no impact in the domain layer, and any change in the domain layer has no impact in the interface layer.

We regard the case of a simple input form. The user can fill in some information regarding his or her name, date of birth, social security number and adress information. This information should be stored in a relational database for later use.

Context

Data volledig scheiden van domein model t.b.v. onderhoudbaarheid. Database heeft andere verantwoordelijkheid dan applicatie en domein laag.

Oplossing:

• Webservice; data wordt door een extern (e.g. Blueriq of 3rd party) worden opgeslagen.
• Blueriq persistentie; wat gaat daarin goed/niet goed? → Domein gedreven en technologie gedreven.
  • Design time bepalen hoe persisteren, Design time niet bepalen hoe persisteren
  • Design time bepaald persistentie en db volgt of database bepaald persistentie en model volgt.
  • Performance getallen
  • Change proces

Solution

Issues and considerations