4. Decoupling [editor]

This section describes manners to decouple your application into several parts. This is needed to reduce the ripple effect that changes in a lower layer have in a higher layer (see 3. Clean Architecture in practice). Before going into details of each pattern, let us have a look at how the decision what pattern to use should be made.

Decision process

When choosing a decoupling pattern, you will roughly make this mental journey:

Starting from top left and going counter-clockwise, we have the following elements. The Application that is to be developed has certain Characteristics (see also 1. Maintainable Applications). Some Characteristics can be

In what parts of the application are frequent changes expected?
Where are additional features expected in the future?
What is the expected life-span?
Do you use the process engine?
Do you have a user interface or a BAAS?
How complex is the domain?
...

Based on the Characteristics, there is a Needed Decoupling Pattern. This pattern is optimal for the Characteristics of your specific Application. With this optimal pattern in mind, you need to match it to the Available Decoupling Patterns. If there is no pattern that is close to the optimal one, you should Propose a New Pattern. As this guide focuses on the domain and business rules for now, a matching pattern for other decoupling opportunities is likely not here yet. Each Available Decoupling Pattern has certain Quality Aspects, which are stated for each. These Quality Aspects need to be matched to the Quality Requirements of the Application that is being developed. These Quality Requirements are often:

Agility
Autonomy
Test-ability
Performance

It might well be that the negative Quality Aspects of a Pattern are not relevant for the Quality Requirements of the Application, and that pattern may be selected. For existing patterns, you can Propose Improvements to the pattern or Blueriq that increase the Quality Aspects of an existing pattern.

Characteristics of Decoupling Patterns

Each decoupling pattern has different characteristics. These characteristics have to match with the quality requirements of your application. As this guide focuses on the domain and business rules for now, 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 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 It should be able to quickly make changes to business rules without breaking 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?
	Out-of-the-box vs. Custom Code	By preference you want everything to be provided by the product. There are patterns possible, however, that need some custom coding.
	Part of Application vs. Separate 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.
	~~Maintainability (=side effects)~~
	Internals invisible/visible	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	Business rules must be easily modeled and executed with Blueriq by using OOTB functionalities.

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.