Versions Compared

Old Version 22

changes.mady.by.user Unknown User (b.de.veer)

Saved on

compared with

New Version Current

changes.mady.by.user Tijmen Daatselaar

Saved on

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
maxLevel2

 

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 layerDomain layerInput 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 decoupling of Deducation rules and front-end. The following characteristcs are important for the implementation.

 PropertyDescriptionDecision ManagementImplicit vs explicit callRelevant business rules should be triggered implicitly. No explicit call (e.g. webservice call) should be neededSimple/Complex parameterAlso a validation of a complexe customer dossier should be possible.Truth maintenanceTruth maintenance will simplify the implementation of deducation rules by only evaluate relevant business rules.Implementation property
TestabilityFront-end and business rules are independently testable.MaintainabilityBusiness rules are easy to maintain. Front-end and domain logic are not intertwined.ReusabilityBusiness rules should be reused easily.

. 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
maxLevel2

Decouple category

Image Added

Out of the boxNo custom code is needed to implement this decouple example.

Decouple category

Image Removed

Properties

Property

Description

Decouple category

Front-end Customer Facing Applications (4)

Complexity

High

Related patterns/solutions

Problem

General application structure

Deducation rules and front-end implementation are closely related to each other. Especially in knowledge intensive applications like request of subsidies and mortgages. Knowledge intensive applications lean strongly on business rules which are available within the front-end. However, maintainability will increase when deducation rules, application logic and UI components are decoupled. This creates a contradication.

This reases the question "how implement knowledge intensive applications without undesirable coupling?"

Image Removed

A general application could be split up in different components (see figure 1). The following components do exist:

  • UI; Front-end with styling, UI manipulation and user interaction.
  • Application logic; Client side application logic like input validation, flows, communication with user and server side logic by means of an API. This part is decoupled from UI and server side components.
  • Business logic; Business rules like deducation rules which must be executed server side because of security reasons. This component also integrates with data, other (external) (web) services.

 

Different variants exist of the general application structure above. The next paragraph uses different variants of the general structure above for difining different solutions. Every solution has properties regarding maintainability which differ.

Knowledge intensity

Depending on the amount of business rules which are directly needed in the front-end without getting "chatty" communication, round-trip delays and complex business rules in the front-end there will be a good or bad fit with the proposed solutions.

 

Knowledge intensity front-endDescriptionLowOnly simple input validation like format validation (e.g. correct phone number, IBAN, postcode), type validation (e.g. only string is allowed), input required or value validation (e.g. age > 18). This kind of applications contains very little business logic. CRUD applications.HighComplex and strongly related deducation rules with a strong declarative character. E.g. rules regarding mortgages, subsidies, legislation, etc.

Important requirements for intelligent dialogs:

  • Single point of definition, multiple points of execution.

 

 

Solutions

Different solutions are possible for implementing intelligent front-ends. Intelligent front-ends do have different characteristics compared with dumb front-ends. Despite the fact that this article is about intelligent front-ends, dumb front-ends are included.

Image Removed

The solution differ in the extend of decoupling between client and server side logic.

 PropertyStrong decoupled front-end

Weak decoupled front-end

Integrated front-end

Decision ManagementImplicit/explicit call

(green star)1/(red star)2

Explicit

(green star)1/(red star)2

Explicit

(green star)

Implicit

Simple/Complex parameter

(green star)1/(red star)2

Simple

(green star)

Complex

(green star)Truth maintenance(green star)1/(red star)2(green star)(green star)

Implementation property

Testability(green star)(green star)(red star)Maintainability(green star)(green star)(red star)

Autonomy (CA layers)

(Don't confuse with application autonomy)

(green star)(green star)

(red star)

UI seperated from application logic(green star)(green star)(red star)Out of the box

(red star)

Only BaaS OOTB

(star)

Only custom UI, and UI REST API OOTB

(green star)

1Non-knowledge intensive front-end.

2Knowledge intensive front-end.

Strong decoupled front-end

A strong decoupled intelligent front-end has different advantages and disadvantages. Hence, it is not advisible to use this solution for intelligent front-ends.

PropertiesStrong decoupled front-endDecision management(green star)1/(red star)2Implementation properties(green star)

1Dumb front-end

2Intelligent front-end

 

The client side logic could be implemented by using custom code (HTML5/CSS?JS).

Server side logic could be implemented and exposed by using BaaS.

Image Removed

Weak decoupled front-end

A weak decoupled intelligent front-end has a few advantages compared to strong and integrated front-ends. This solution is advisable for implementing intelligent front-ends.

PropertiesWeak decoupled front-endDecision management(green star)Implementation properties(green star)

The client side logic could be implemented by using custom code (HTML5/CSS?JS).

Server side logic could be implemented and exposed by using the UI REST API.

Image Removed

Integrated front-end

Standard implementation

An integrated intelligent front-end has a few advantages related to decision management but has a bad score on maintainability. Hence, this solution is not advisable for implementing intelligent front-ends.

PropertiesIntegrated front-endDecision management(green star)Implementation properties(star)1/(red star)2

1Small application

2Large application

 

The client side and server logic is implemented with Blueriq and by stacking modules. See Decoupling Pattern 9: Stacking of modules for more information regarding this pattern. Styling and look and feel of the UI could be realised by custom code (CSS/JS).

Image Removed

Shared domain and support attributes

The maintainability of an integrated front-end could be improved by using support attributes and a shared domain model. By doing this the coupling will be decreased due to support attrbitutes while it is still possible to reuse business rules defined within an external library.

Issues and considerations

Implementing intelligent front-ends is complicated because of maintainability aspects (seperation of concerns and decoupling) and the integrated properties of definition and execution of business rules. This easily creates a contradiction. Decoupling is important for maintainable applications while intelligent dialogs (which contains complex and strongly dependent business rules) are easy to implement by integrating business rules (server-side) with dialog (front-end) components.

The offered solutions do have different properties. When an intelligent dialogs must be implemented solution 2 is highly recommended because it has good implementation and decision management properties.

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
titleExpand to see the External Rule pattern characteristics

Include Page
Decoupling Pattern 6: External Rule Score [Internal]
Decoupling Pattern 6: External Rule Score [Internal]

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
titleExpand to see the Module with Flow pattern characteristics

Include Page
Decoupling Pattern 1: Module with Flow Score [Internal]
Decoupling Pattern 1: Module with Flow Score [Internal]

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.