Summary

In dialogs different types of validations are used. There are validations which define when a value is valid at all, and there are validations which are rules defined by the business. For example an date of birth is only a valid date of birth if it is not in the future. The business however wants only to allow applicants of 18 years or older, so the date of birth should be 18 years or more in the past.

Speaking in terms of the clean architecture, the validation rules that indicate whether a value is valid at all are located in the interface layer. The validation rules which are determined by the business are part of the domain layer. This article discusses the second kind of validation, and how not to mix the interface layer with the domain layer.

Problem

Business rules and validations deserve special attention in Blueriq. Please see Business Rules and the Clean Architecture for more information.

In this small example, we discuss the case that the business imposes that an applicant should be 18 years of age. For this scenario it is important that the rule engine triggers automatically and no flow is needed and that Blueriq can provide support with features such as dependencies and the decision requirements graph.

Solutions

No decoupling

As this example is tiny, doing no decoupling at all is a valid option. A validation rule can be created for checking that the applicant is old enough. The logic for this calculation is placed inside the Validation rule. This approach is not only simple to implement, it also fullfils the requirement that it is triggered automatically and that dependencies work.

Module with Flow

In this pattern we create a boolean support attribute which indicates whether the applicant is old enough. The attribute and business rule can be placed in a separate module. As such, these rules can be distributed easily and tested separately using studio unit tests. The validation rule then simply checks whether this attribute has value true.

Expand to see the Module with flow pattern characteristics

	Type	Score	Description
Knowledge characteristics	User set or System set	System set	As the underlying module is included, the rule engine can do its work.
	Parameters or complex model	Complex Model	The entire function can be used as output. There are no clear input parameters defined.
	Enhanced by Blueriq Functionality		This pattern is enhances by Blueriq functionality, as model validations, the Decision Requirements graph, dependencies and specifications keep working.
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality.	Focus on Internal or External Use	Internal	This pattern purely covers internal use. The business function is included in a Blueriq library.
	Low Implementation complexity		Including a library is done quickly and easily. The complexity can however increase drastically in case that many libraries are used and stacked, or if many projects need updates from the same library. When many specializations are present, then the complexity is high.
	Internals invisible (encapsulation)		All internals are visible and increase the mental load of the business engineer. Mistakes may be made when elements are used which were not supposed to be used.
	Autonomous		The business rules are executed in the context of the main application. When the main application uses internals of the library, then making changes generates side effects.
	Highly Testable		The library can be tested on its own, either by unit tests in studio or with special test applications. When the application gets larger testing larger chunks of model can get difficult.
	Highly Reusable		Including libraries by hand can be time-consuming when the number of projects becomes large. The Blueriq Control Center can help with many projects.
	Out of the Box		This is possible without custom coding.
Deployment characteristics	Part of Application or Separate Deployment (=deployment)	Part of Application	The library has to be imported into a project and becomes part of it.

Issues and considerations

We advise to use the Decoupling Pattern 1: Module with Flow for this example. It fullfils all requirements, and gives additional support in the form of unit tests in studio. There is also a neat separation of business validations and general validations. Applying no decoupling can still be a valid option if the overall application is small, but this choice should be revisited when the application grows.