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. The moment of storage should be determined by a flow, and the rule engine plays no role in this example.

Solutions

Webservice

The storing of information can be done by a web service. Often existing back-end systems have such a web service already in place. In Blueriq we create a separate module for the contract definition and create a datamapping for the translation. This pattern is a suitable fit as the domain model stays clear of any database specifics or contract specifics. The translation is created and maintained within Blueriq, and all functionality is available out-of-the-box.

Aggregates

Blueriq makes use of Aggregate for persistence. This can be seen as a decoupling pattern specifically aimed at this scenario. The domain model is serialized and stored as one chunk. This means that changes in the domain do not influence the database structure. The model is also oblivious to where the data is stored, and the database can be exchanged as needed.

If the data is from a greenfield situation, the out-of-the-box functionality may suffice. In case an existing database should be coupled to the aggregates, the Persistence API for customer data can be used. This has the great advantague that the model stays clean from database specifics. The drawback is that a translation has to be made in code.

Issues and considerations

The best option for this example depends on if there is a green field situation or not, and if there is the possibility to write custom code. We can summarize the preferred choice in the below table.

The great advantage of Aggregates are that the model stays clean from any data base specifics, and this should be promoted as much as possible. The web service is good option if no custom code can be written and a connection to an existing data base has to be made. It comes with a drawback that a possibly complex data mapping has to be made and maintained.