Dialogues can be strongly dependent on business rules. These business rules are intended for the realization of intelligent forms of an application. In order to prevent the necessary business rules from interfering with the various layers within the application, the dialogues and the implementation of the business rules must be properly set up. It is important that it is still possible to use true maintenace and at the same time apply sufficient decoupling.
Contents
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 Deducation rules only. The following characteristcs are important for the implementation.
Property
Description
Decision Management
Implicit vs explicit call
Relevant business rules should be triggered implicitly. No explicit call (e.g. webservice call) should be needed
Simple/Complex parameter
Also a validation of a complexe customer dossier should be possible.
Truth maintenance
Truth maintenance will simplify the implementation of deducation rules by only evaluate relevant business rules.
Implementation property
Testability
Front-end and business rules are independently testable.
Maintainability
Business rules are easy to maintain. Front-end and domain logic are not intertwined.
Reusability
Business rules should be reused easily.
Out of the box
No custom code is needed to implement this decouple example.
Problem
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.
Scenarios:
thin, next step is not determined by dialog. Business rules served by back-end
thick, next step is determined by dialog. Business rules/flows executed by front-end
Property
Integrated dialog
Thick front-end, API, BQ back-end
Shared domain model for BQ dialog and support attributes
Thin Custom front-end, API, BQ back-end
(HTML response, front-end integration, NN)
REST UI API
thin front-end
(styling fully adaptable)
(JSON, AAL)
Decision Management
Implicit vs explicit call
implicit
explicit
Simple/Complex parameter
Truth maintenance
Implementation
property
Testability
Maintainability
Autonomy (CA layers)
don't confuse with application autonomy
domain attributes in dialogs
domain attributes via support attributes in dialog
Out of the box
*Business rules implemented in code, not in Blueriq.