Page History
...
| Type | Description | |
|---|---|---|
| Knowledge characteristics | Implicit vs. 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 vs. System set | Should values be user or system set? This may be important for the rule engine | |
| Input and Output parameters vs. 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. (????) | |
| Simple input vs complex input | Mapping of complex domain models. | |
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Internal vs. External | 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. |
| Automated vs. User Interaction | When user interaction is needed, the function should stay within the project. If this is not the case, a function-like style of decoupling can be chosen. | |
| Complexity of the Decoupling pattern vs Gain | 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 vs. 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 vs visible (encapsulation) | Internals of decoupled functions is invisible or visible for the requesting application. | |
| Testable | It must be easy to test the functionality. | |
| Autonomy/decoupling | 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. | |
| Reusability | Calculations often have to be reused within the Blueriq application landscape. | |
| Out of the box vs. Custom Code. | 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. |
...
For decoupling a business function a.k.a domain service of the domain layer, such as a business decision or calculation, we generally advise patterns Decoupling Pattern 2: Webservice call and Decoupling Pattern 6: External Rule. You need to match the pattern to your specific situation however.
...
Overview
Content Tools