Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Properties
Property
Description
Ontkoppel categorie
Front-end (4)
Complexiteit
Laag
Table of Contents | ||
---|---|---|
|
Summary
In dialogs many input validation rules different types of validations are used. Some (input) validations will be defined within the domain layer and used within dialogs (interface layer), others are only defined and used within dialogs (e.g. correct birthday, telephone numbers, etc.). Validation rules defined within the domain layer will cause coupling between dialogs and business rules which will leads to many undesirable effects.
Image Removed
Context
Input validations and suport attributes.
Input validation
(front-end only)
Business rule validation
(defined in domain, also used in front-end)
Probleem
Content of a value list changes more often compared to the application which uses the value list. Seperating application behaviour from maintenance of value list content which could be depend on external resources.
Oplossingen
Voor de oplossing wordt rekening gehouden met de kenmerken die benoemd zijn in de tabel onder "Context".
Er zijn verschillende oplossingen mogelijk waarbij de bovenstaande kenmerken in meer- of mindere mate gerealiseerd kunnen worden. Per geval dient de best passende oplossing te worden gekozen. In de tabel hieronder worden de belangrijkste eigenschappen getoond en hoe elke oplossing daarop scoort.
characteristic
Solution 1
Solution 2
Issues and considerations
Related patterns
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.
Contents
Table of Contents | ||
---|---|---|
|
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.
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
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.
Decouple category
Image Added
Properties
Property | Description |
---|---|
Decouple category | Customer Facing Applications (4) |
Complexity | Low |
Related patterns/solution |
|