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 high business value and must be easily maintainable and implemented atonomously.
Different kinds of business 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? (operational business rules) | What is the next step? Which activity is not allowed? (Business rules based on law and organizational policy) | |
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.
| Property | Description | |
|---|---|---|
| Decision Management | Implicit vs explicit call | Input validation should be triggered implicitly. No explicit call should be needed. |
| Truth maintenance | Truth maintenance will simplify the implementation of input validation. | |
| Implementation property | Testability | Front-end and business rules are independently testable. |
| Maintainability | Input validation rules are easy to maintain. Input validation are only implemented within the front-end and are not intertwined with other domain logic. | |
| Out of the box | Input validation is implemented by means of OOTB input validation rules. |
Problem
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 below.
| Property | Support attributes | Validation rule | |
|---|---|---|---|
| Decision Management | Implicit vs explicite call | implicit | implicit |
| Truth maintenance |  | | |
Implementation property | Testability |
| |
| Maintainability |  |
| |
| Out of the box | | |
*Business rules implemented in code, not in Blueriq.
Validation rule
Input validations could be easily implemented with Validation rules. By using Validation Rules it will be harder to mix it with the application and domain layer. See Validation rules for a full explanation of this feature.
Support attributes
Support attributes are attributes only used for input validation. The expression field of an attribute is used to define the input validation. Only this attribute is used within a container. See MyBlueriq for a full explanation of Attributes.
Issues and considerations
By using input validations it is easy to implement input validations which are seperated from the application and domain layer. Support attributes could be used as well but it will take more time to implement but is harder to prevent coupling with other layers.
Decouple category
Properties
| Property | Description |
|---|---|
| Decouple category | Front-end (4) |
| Complexity | Low |
| Related patterns/solution |
Overview
Content Tools