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 Some business rules needed for intelligent forms are from interfering with the various domain layers within the application, the dialogues and the implementation as they concern the core logic 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)
- 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?
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.
. Other rules are created just to make the page more dynamic and give the end user a better experience. The latter are located in the user application layer.
In this example we regard a problem diagnosis for house repairs. When something breaks in your house you want to indicate the problem to the landlord so that a propert repair can be scheduled. What is exactly broken can not be known by the inhabitant, but is important to know so that the appropriate equipment is brought for the reparation.
Problem
When there is a problem in the household, the landlord can be called with a desciption of the problem. The landlord asks clarification questions in order to dispatch the correct repairman. In case that the user comes to a Blueriq application with the problem, the same clarification questions need to be asked. The difference to a standard input form is that the next question to be asked to the end user is highly dependent on the answers give so far. The end user should only get relevant questions and as few as possible to come to a conclusion about the problem.
A great example is the case of the pilot light in the water boiler. If this small fire is distinguished, no warm water is produced and so components as the radiator or the shower may not work. The inhabitant however has no idea what a pilot light is, and goes to the Blueriq application with a problem in mind: my house is cold. What questions should we ask the end user in order to deduce that there is a pilot light problem?
Examples could be:
- Do you hear water running when you turn the radioator on?
- Is there warm water in the shower?
- Does your light turn on?
- Do you see a small flame in the water boiler?
- Possibly preceeded by "Do you know where your water boiler is and how it looks like?"
In Blueriq both the domain logic and page logic is modelled using Business Rules and Decision Tables. In an example such as this, the preconditions on the page might be heavily dependent on domain knowledge. We have to think carefully on what is page specific and belongs in the interface layer, and what is domain knowledge and belongs in the domain layer.
Important factors for this problem is the truth maintenance of the rule engine, The end user has the possibility to change earlier answers and there is no manner to handle this in the flow in a maintainable manner. We therefore only consider patterns which derive system-set values.
Contents
Table of Contents | ||
---|---|---|
|
Decouple category
Image Added
Properties
Property | Description |
---|---|
Decouple category | Customer Facing Applications (4) |
Complexity | High |
Related patterns/solutions |
|
Solutions
External rule
The precondition whether a question should be shown to the user can be determined by an attribute which uses an external rule. The external rule uses much domain knowledge to derive its answer, and it has to be aligned with other external rules for different attributes. This can be challenging, if not impossible to achieve. Furthermore is the knowledge hidden in code, and not in Blueriq.
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Module with Flow
We split the application into two modules, one with all logic of the domain, and one containing logic for the application. The latter is stacked on the former to make use of its content. The advantage of this approach is that the rule engine can do its work and supporting features of Blueriq are available. With a clear differentiation in module, and in naming of the domain it can be clear to the business engineer what is located where. What is not clear is what part of the business domain is internal. This can lead to unwanted side effects when refactoring.
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
|
Issues and considerations
With the current possbilities in Blueriq, we advice to use Decoupling Pattern 1: Module with Flow [editor]. One has to clearly indicate what attributes can be used and act as interface and which do not.
One approach which one may look at are conversations (decision trees). With this approach there exists no page specific logic at all, as the page content is created dynamically based on rules in the domain layer. We regard decision trees as a pattern which specifically addresses the separation of the user interface layer and the domain layer, and it can not be used in a different context. One drawback of the decision tree is that all control of the page structure is transfered to the rule engine. If the generated pages are not satisfactory, no tweaking is possible.
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 Removed
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
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)
implicit
explicit
Implementation property
Autonomy (CA layers)
don't confuse with application autonomy
domain attributes in dialogs
domain attributes via support attributes in dialog
*Business rules implemented in code, not in Blueriq.
Solution 1
Solution 2
Issues and considerations
Decouple category
Image Removed
Properties
Property
Description
Decouple category
Front-end (4)
Complexity
High