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:
...
- 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?
- ...
- Agility
- Autonomy
- Test-ability
Performance
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:
...