You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Properties

Property

Description

Decouple category

Front-end (4)

Complexity

Low

Related patterns/solutions

 

 

Summary

In dialogs many input 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 (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

  • Can we process this value?
  • Is value required?
  • Correct telephone number
  • Correct birthday
  
Authorization 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 rules

 

 

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

 

 

 EigenschapOmschrijving
Kennis ontsluitingImplicit vs explicit call 
Simple/Complex parameter 
Truth maintenance 
Implementatie kenmerkenTestableFront-end and business rules are independently testable.
 MaintainableBusiness 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.

 

 EigenschapSupport attributesValidation service  
KnowledgeImplicit vs explicit callimplicitexplicit  
Simple/Complex parameter    
Truth maintenance(green star)(red star)  
Implementation
characteristic
Testable(green star)(green star)*  
Maintainable(star)

(star)*

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

*Business rules implemented in code, not in Blueriq.

Support attributes

 

Validation service

 

Issues and considerations

 

Related patterns

 

 

 

  • No labels