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 unit tests in you model. The validation rule then simply checks whether this attribute has value true.

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 your model. 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.