Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Summary
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
Table of 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.
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 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.
Image Added
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 | ||||
UI seperated from application logic | ||||||
Out of the box |
*Business rules implemented in code, not in Blueriq.
Solution 1
Solution 2
Issues and considerations
Decouple category
Properties
Property | Description |
---|---|
Decouple category | Front-end (4) |
Complexity | High |
Related patterns/solutions |
|