Decoupling Pattern 4: Custom decision service [editor]

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	Description
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.
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.
Out-of-the-box vs. Custom Code	A new service has to be created by a developer.
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.
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.