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.

Expand to see the Webservice call pattern characteristics

 

 

	Type	Score	Description
Knowledge characteristics	User set or System set	User set	User-set values enter the profile, which are set from the returning message and the subsequent data mapping.
	Parameters or complex model	Parameters	Only simple input/output parameters could be used with Web services (BaaS). The input and output parameters are neatly defined in the contract of the web service. You are able to steer what values are set in the data mapping. If you want to fill in the  parameters differently for different calls from the same module, an additional data mapping and AQ_WebServiceClient service call needs to be created.
	Enhanced by Blueriq Functionality		Blueriq can use dependencies up to the contract. There are no decision requirement graphs or dependencies possible between the calling application and the BAAS.
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality.	Focus on Internal or External Use	External	A web service is intended for external use, and relies on an official contract definition.
	Low Implementation complexity		You get two additional modules in your project, and a second project next to it. As you are in control of the information being send, the structure will be similar to what you use in the application module. Therefore the mapping should be easy (1 to 1). You have to create your own contract for the communication, and keep this updated.
	Internals invisible (encapsulation)		Internals are not visible and/or accessible of a web service.
	Autonomous		The business rules are executed in a separate profile, and no side-effects are possible.
	Highly Testable		Webservices are easily testable.
	Highly Reusable		A BaaS implementation is not very reusable because of a lack of parameter support. Hence, for every web service call a mapping must be defined.
	Out of the Box		No custom code required in general.
Deployment characteristics	Part of Application or Separate Deployment (=deployment)	Separate Deployment	As soon as a new version is deployed, all consumers directly use the new version. When web services are versioned, the calling party can decide itself when to migrate to a new version.

 

 

Aggregates

Blueriq makes use of Aggregates 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.