Page History
...
...
Characteristics of Decoupling Patterns
Each decoupling pattern has different characteristics. These characteristics have to match with the quality requirements of your application.
we state the characteristics that are most important for this type of decoupling. Other characteristics may be interesting for other decoupling types.Type | Description | ||||
---|---|---|---|---|---|
Knowledge | Implicit vs. Explicit callcharacteristics | User set or System set | Is there a certain moment when you want to make a decision (explicitly), or do you want that the rule engine with its truth maintenance takes over and derives the value when needed (implicitly)? | ||
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. Parameters or complex model | For decoupling, ofteninput and output parameters are needed , which could beThese parameters receive a value from attributes in your domain. MaybeIn the most extreme cases, no parameters are needed at all, or the complete domain of the function is still present, and no in- or output parameters are needed. If only a small reduction takes placeacts as input. Certain patterns favor simple parameters, others favor complex parameter sets. In case that a large part of the domain is needed is input, and your domain can not be simplified significantly, then you might choose not to decouple. | ||||
Simple Parameters vs. Complex Instances | A decoupled function might only need few input parameters to function. Sometimes a large domain with multiton instances with relations is needed. | ||||
apply any of the presented decoupling patterns. | |||||
Enhanced by Blueriq Functionality | Blueriq has certain features in studio, such as model validations, the Decision Requirements graph, dependencies and specifications which help in creating and maintaining complex applications. Depending on the pattern, these feature can or can not be used. | ||||
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality. | Focus on Internal or External Use | The | Implementation charateristics | Internal vs. External | The decoupled functionality might only be used internally, favoring certain decoupling mechanisms. This makes the contract simpler to maintain, as both the exposer and consumer are under control. If the functionapplication 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. | ||||
the contract to the outside world can not be changed as easily. | |||||
Low Implementation complexityComplexity 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 costs? | ||||
Internals invisible (encapsulation) | Internals of decoupled functions is invisible or visible for the requesting application. When the internals are not visible, it reduces the mental load on the Business Engineer as well as prevents errors when the internals are used. Business rules must be executed autonomously and have no dependencies with other application features. When this is achieved, the internals can be safely refactored without side-effects. | ||||
Autonomous | Business rules must be executed autonomously and have no dependencies with other application features. With a strict separation, side-effects of changes are impossible. When only the internals are hidden (see above), then it might still be possible to have side-effects. However, a knowledge-model may embrace all business rules without decoupling every single rule. | ||||
Highly Testable | It must be easy to test the functionality. This includes manual as well as automated tests. | ||||
Highly Reusable | Calculations often have to be reused within the Blueriq application landscape. Certain patterns make a component easier to be re-used than other patterns. | ||||
Out of the Box | 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. | ||
Deployment characteristics | Part of Application vs. Separate DeploymentDeployment Granularity | 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 Or the decoupled part can be deployed completely independently, meaning so that when it is published, all projects that use this feature are directly using the new version. | Maintainability (=side effects) | How easy it is to make changes that do not affect other functionality.Internals invisible/visible | Internals of decoupled functions is invisible or visible for the requesting application. |
Testable | It must be easy to test the functionality. |
...
Design Patterns
These are the decoupling patterns that are available for decoupling domain and business rules.
...
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.
...