Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary

In dialogs different types of validation rules validations 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 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 usedThere 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
maxLevel2

 

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

  • 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?
  

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

 

 

  • Are the various choices compatible?
  • Is this application acceptable?
  • Calculation
  • Decision based on policy rule

 

This article will focus on Input Validation only. The following characteristcs are important for the implementation of input validation.

 PropertyDescriptionDecision ManagementImplicit vs explicit callInput validation should be triggered implicitly. No explicit call should be needed.Truth maintenanceTruth maintenance will simplify the implementation of input validation.Implementation property
TestabilityFront-end and business rules are independently testable.MaintainabilityInput 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 boxInput validation is implemented by means of OOTB input validation rules.


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

Module with Flow

Expand
titleExpand to see the Module with flow pattern characteristics

Include Page
Decoupling Pattern 1: Module with Flow Score [Internal]
Decoupling Pattern 1: Module with Flow Score [Internal]

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

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.

 

 PropertySupport attributesValidation ruleDecision ManagementImplicit vs explicite callimplicitimplicitTruth maintenance(green star)(green star)

Implementation property

Testability

(star)

(green star)Maintainability(star)

(green star)

Out of the box(green star)(green star)

*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

Image Removed

Properties

PropertyDescription
Decouple categoryFront-end Customer Facing Applications (4)
ComplexityLow
Related patterns/solution