Versions Compared

Key

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

Properties

Property

Description

Decouple category

Front-end (4)

Complexity

Low

Related patterns/solutions

 

Table of Contents
maxLevel2

Summary

In dialogs many input different types of validation rules 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 This article only focus on input validation (e.g. correct valid birthday, telephone numbersnumer, etc.) . Validation rules defined within the domain layer will cause coupling between dialogs and business rules which will leads to many undesirable effectswhich is only defined within the dialog. This kind of validation rules 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 do have a special 

  • 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?
  
Authorization/authenticatie rules 

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 rulesdeclarative rules

 

 

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

 

 

 EigenschapOmschrijving
Kennis ontsluiting
KnowledgeImplicit vs explicit call 
Simple/Complex parameter 
Truth maintenance 
Implementatie kenmerken
Implementation properties
Testable
TestabilityFront-end and business rules are independently testable.
 
Maintainable
MaintainabilityBusiness rules are easy to maintain. Front-end and domain logic are not intertwined.
 Out of the box 

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 

 

 
 PropertySupport attributesValidation service  rule
KnowledgeImplicit Implicite vs explicit explicite callimplicitexplicit impliciteexplicite 
Simple/Complex parameter   
Truth maintenance(green star)(red star)  
Implementation
property
Testability(green star)(green star)*  
Maintainability(star)/(red star)

(star)*

  

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

*Business rules implemented in code, not in Blueriq.

Support attributes

 

Validation

service

rule

 

Issues and considerations

 

Related patterns