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 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.
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 | Support attributes | Validation service | 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 | | | | ||||||
Implementationproperty | Testability | | * | ||||||
| Maintainability | | | | Maintainability | | ||||
Autonomy (CA layers) don't confuse with application autonomy | | | * | ||||||
| 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 |
Overview
Content Tools