Page History
Properties
Property
Description
Decouple category
Front-end (4)
Complexity
Low
| 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.
Context
- Input validations and suport attributes.
- op een plek definieren zodat onderhoud eenvoudig is. Weinig werkt.
- Validatie service
Different rules exists in every layer within the clean architecture.
Interface layer
(front-end)
Application layer
Domain layer
Input validation
- Format validation (e.g. correct phone number, IBAN, postcode)
- Type validation (e.g. only string is allowed)
- Input required
- Value validation (e.g. age > 18)
- Can we process this value?
Can this user (role) see/modify this?
Can they overrule these warnings?
What is the next step?
Which activity is not allowed?
Deducation/integrity/calculation rules
e.g. Product/underwring/policy/law rules
declarative rules
- Are the various choices compatible?
- Is this application acceptable?
- Calculation
- Decision based on policy rule
Problem
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.
Solutions
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.
Pim:
- Validatieregels
property*
/*
*Business rules implemented in code, not in Blueriq.
Support attributes
Validation service
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
Properties
| Property | Description |
|---|---|
| Decouple category | Customer Facing Applications (4) |
| Complexity | Low |
| Related patterns/solution |
Overview
Content Tools