This pattern is similar to Decoupling Pattern 3: Custom service to retrieve data. The main difference is that the service itself now takes the decision, which in Pattern 3 is taken in the profile.
Characteristics
| Type | Score | Description | |
|---|---|---|---|
| Decision Management | Rule Engine | ||
| Truth maintenance | |||
| Implicit vs. Explicit call | This is an explicit call. The rule engine does not trigger the function. | ||
| User set vs. System set | The service does not set any value. | ||
| Implementation properties | Input and Output parameters vs. Complex Model | There is no definition in studio of what the input parameters are. There are no output parameters, as the events of the service handle the decision. The service has the complete profile as input, but might only need a small amount of it. No additions are needed in the domain, any internals are hidden in the service. | |
| Simple Parameters vs. Complex Instances | These can be simple and complex, depending on the need. | ||
| Internal vs. External | This type of decoupling is only for internal use. | ||
| Automated vs. User Interaction | This type of decoupling is only for automatic tasks. | ||
| Complexity of the Decoupling pattern vs Gain | As including such a service is easy, the complexity is low. Creating the service itself is also not complex. | ||
| Part of Application vs. Separate Deployment | The decoupled function is partly in the model, and partly in code. You should make sure that the code is deployed together with the project. | ||
| Testability | |||
| Autonomy | |||
| Maintainability | This pattern does not clutter your domain with unnecessary attributes, which is an advantage. A disadvantage is that it is not clear to the business engineer what input the service needs. For example, you can not use the dependency function in studio to find input attributes. Another disadvantage is that the decision is made inside the service. Such decisions should be made in studio, as that is why there is a rule engine; to make decisions visible and traceable. Any changes to this decision require changes in the code. | ||
| Reusability | |||
| Out-of-the-box vs. Custom Code | A new service has to be created by a developer. |
Overview
Content Tools