Page History
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 |
| ||
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 decoupling of Deducation rules and front-end. 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. |
Decouple category
Properties
Property | Description |
|---|---|
Decouple category | Front-end (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?"
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-end | Description |
|---|---|
| Low | Only 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. |
| High | Complex 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.
The solution differ in the extend of decoupling between client and server side logic.
| Property | Strong decoupled front-end | Weak decoupled front-end | Integrated front-end | |
|---|---|---|---|---|
| Decision Management | Implicit/explicit call |
Explicit |
Explicit |
Implicit |
| Simple/Complex parameter |
Simple |
Complex |  | |
| Truth maintenance | 1/ 2 | | | |
Implementation property | Testability | | | |
| Maintainability | | | | |
Autonomy (CA layers) (Don't confuse with application autonomy) | | |
| |
| UI seperated from application logic | | | | |
| Out of the box |
Only BaaS OOTB |
Only custom UI, and UI REST API OOTB | |
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.
| Properties | Strong decoupled front-end |
|---|---|
| Decision management | 1/2 |
| Implementation properties | |
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.
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.
| Properties | Weak decoupled front-end |
|---|---|
| Decision management | |
| Implementation properties | |
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.
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.
| Properties | Integrated front-end |
|---|---|
| Decision management | |
| Implementation properties |  1/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).
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.
Overview
Content Tools