Page History
...
| Type | Description | ||||
|---|---|---|---|---|---|
| Knowledge characteristics | Implicit or Explicit call | Is there a certain moment when you want to make a decision, or do you want that the rule engine with its truth maintenance takes over and derives the value when needed? | |||
| User set or System set | Should values be user or system set? This may be important for the rule engine | ||||
| Parameters or complex model | For decoupling, often input and output parameters are needed, which could be attributes in your domain. Maybe the complete domain of the function is still present, and no in- or output parameters are needed. If only a small reduction takes place, then you might choose not to decouple. A decoupled function might only need few input parameters to function. Sometimes a large domain with multiton instances with relations is needed. (????) | ||||
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Internal or External decoupled | The decoupled functionality might only be used internally, favoring certain decoupling mechanisms. If the function is also valuable externally, then creating a web service may be interesting. Internal decoupling supports: model validation, implicit calls, system set attributes, DRG | |||
| Implementation complexity | Each pattern increases the complexity of the model, and some more than others. Does the gain weigh up against the cost complexity? | ||||
| Part of Application or Separate Deployment (=deployment) | The pattern can be included in the project, meaning that only when a new version of the application is published the decoupled part is published. It could also be that the decoupled part can be deployed completely independently, meaning that when it is published, all projects that use this feature are directly using the new version. | Internals invisible (encapsulation) | Internals of decoupled functions is invisible or visible for the requesting application. | ||
| Testable | It must be easy to test the functionality. | ||||
| Autonomous/decoupled | How easy it is to make changes that do not affect other functionality. Business rules must be executed autonomously and have no dependencies with other application features. | ||||
| Reusable | Calculations often have to be reused within the Blueriq application landscape. | ||||
| Out of the Box | Business rules must be easily modeled and executed with Blueriq by using OOTB functionalities. By preference you want everything to be provided by the product. There are patterns possible, however, that need some custom coding. | ||||
| Deployment characteristics | Part of Application or Separate Deployment (=deployment) | The pattern can be included in the project, meaning that only when a new version of the application is published the decoupled part is published. It could also be that the decoupled part can be deployed completely independently, meaning that when it is published, all projects that use this feature are directly using the new version. | |||
Design Patterns
These are the decoupling patterns that are available for decoupling domain and business rules.
...
Overview
Content Tools