Page History
Properties
Property | Description |
|---|---|
Decouple category | Front-end (4) |
Complexity | Low |
| Related patterns/solutions |
| Table of Contents | ||
|---|---|---|
|
Summary
In dialogs different types of validation rules are used. This article only focus on input validation (e.g. valid birthday, telephone numer, etc.) which is only defined within the dialog. This kind of validation rules rule won't create coupling with the domain layer. Different solutions are possible which are discussed. Depending on the context a Blueriq validation rule or a support attribute should be used.
Context
Different kind of rules are used within an application. Business rules gets a special attention compared to design rules. Business rules do have a special
- Input validations and suport attributes.
- op een plek definieren zodat onderhoud eenvoudig is. Weinig werkt.
- Validatie service
high business value and must be easily maintainable and implemented atonomously.
Different kinds of business Different rules exists in every layer within the clean architecture.
Interface layer (front-end) | Application layer | Domain layer | |
|---|---|---|---|
Input validation |
| ||
Authorization/authenticatie rules (cross-cutting concern) | Can this user (role) see/modify this? Can they overrule these warnings? | ||
| Process rules |
| What is the next step? Which activity is not allowed? | |
Deducation/integrity/calculation rules e.g. Product/underwring/policy/law rules |
|
|
This article will focus on Input Validation only. The following characteristcs are important for the implementation of input validation.
| EigenschapProperty | OmschrijvingDescription | |
|---|---|---|
| Knowledge | Implicit vs explicit call | |
| Simple/Complex parameter | ||
| Truth maintenance | ||
| Input validation should be triggered implicitly. No explicit call should be needed. | ||
| Truth maintenance | Truth maintenance will simplify the implementation of input validation. | |
| Implementation properties | Testability | Front-end and business rules are independently testable. |
| Maintainability | Business Input validation rules are easy to maintain. FrontInput validation are only implemented within the front-end and domain logic are not intertwined with other domain logic. | |
| Out of the box | Input validation is implemented by means of OOTB input validation rules. |
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".
Input validations are part of business rule but must only be implemented within Blueriq dialogs (=front-end). When input validations are mixed up with other business and design rules it will complicate the maintainability. Seperate input validations which only exist in the interface layer from other layers (application and domain layer).
Solutions
Below a few solution will be described to implement input validations. The properties of the solutions will be shown in the table belowEr 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.
| Property | Support attributes | Validation rule | |
|---|---|---|---|
| Knowledge | Implicite Implicit vs explicite call | impliciteimplicit | explicite |
| Simple/Complex parameter | |||
| implicit | |||
| Truth maintenance |  |  | |
Implementationproperty | Testability |
| * |
| Maintainability |  / |
| |
| Out of the box | | |
*Business rules implemented in code, not in Blueriq.
Support attributes
Validation rule
Issues and considerations
Related patterns
Overview
Content Tools