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 onlyand 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. |
Problem
Solutions
Voor de oplossing wordt rekening gehouden met de kenmerken die benoemd zijn in de tabel onder "Context".
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 rease 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). |
| High | Complex and strongly related deducation rules with a strong declarative character. E.g. rules regarding mortgages, subsidies, legislation, etc. |
Solutions
Application
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 |  | |||
| Solution 1 Strong decoupled front-end | Solution 2 Weak decoupled front-end | Solution 3 Integrated front-end | |||||
| Decision Management | Implicit/explicit call |
Explicit |
Explicit |
Implicit | |||
| Simple/Complex parameter |
 Simple |
Complex |  | ||||
| Truth maintenance | 1/2 | | | ||||
Implementation property | Testability | | | | |||
| Maintainability | | Maintainability | | | | | |
Autonomy (CA layers) don't confuse with application autonomy | | |
domain Domain attributes in dialogs | |
domain attributes via support attributes in dialog | ||
| UI seperated from application logic | | | | | |||
| Out of the box |
Only BaaS |
Only custom UI | |
1Non-knowledge intensive front-end.
2Knowledge intensive front-end.
*Business rules implemented in code, not in Blueriq.
Solution 1
Strong decoupled front-end
A strong decoupled front-end
Solution 2 Weak decoupled front-end
REST UI API
Solution 3 Integrated front-end
Standard implementation
Shared domain and support attributes
Solution 2
Issues and considerations
Decouple category
Properties
Property | Description |
|---|---|
Decouple category | Front-end (4) |
Complexity | High |
| Related patterns/solutions |
Overview
Content Tools