Page History
This decoupling pattern places the business function into a separate module which is included in the project as a library. This library can be internal or external. The library includes a flow that decides on a certain question. The result is indicated by the two exits of the flow. As the domain is included in the parent module, the complete profile is shared.
Characteristics
| Type | Score | Description | |
|---|---|---|---|
| Decision ManagementManagement | Rule Engine | ||
| Truth maintenance | |||
| Simple Parameters vs. Complex Instances | Anything can be used by the function as input, also multiton instances. | ||
| Implicit/Explicit call | This is an explicit call. The rule engine does not trigger the function. | ||
| User/System set | Can be both. If the flow only uses the rule engine, then all used attributes are system-set. | ||
| Implementation properties | Input and Output parameters vs. Complex Model | There are no input parameters, as the complete profile is shared. This means that (part of) the domain of the function should be filled by the application module. You therefore have a complex model, as everything from the function is part of your model. | |
| Internal vs. External | This type of decoupling is only for internal use. | ||
| Automated vs. User Interaction | Any user action required can be included in the sub-flow. | ||
| Complexity of the Decoupling pattern vs Gain | The use of such a sub-flow is straightforward, and not complex. | ||
| Part of Application vs. Separate Deployment | The decoupled function is part in the model. | ||
| Testability | |||
| Maintainability | As the function is included as library, any part of it can be used inside the application module. This means that any change in the library can break the application module. This is noticed late, when a new version of the (external) library is imported into the project. | ||
| Autonomy | |||
| Reusability | |||
| Out-of-the-box vs. Custom Code | No custom code required. |
Overview
Content Tools