Summary

This example concerns the decoupling of the interface layer with the use case layer (arrow 4). When changing the personal information of a customer, we want to highlight which steps are still to be performed until the change was completed.

Problem

On almost any application created by Blueriq, personal information such as a name and an address have to be supplied. Once a person is a customer, a need arises for making changes to the personal information, as one might marry or move. One might even need to change the date of birth. Not as it changed, as that is impossible, but because incorrect input was supplied earlier.

When personal information changes, certain validations need to be performed. For example is a subsidy only applicable to inhabitants of a certain region. We therefore define the changing of personal information as a use case, which is placed in the applications layer.

The use case describes the necessary steps for making the changes to the personal information. In this example the use consists of these steps. The customer should see a page where changes can be made, after which possibly an employee has to perform a manual check, and finally all systems are updated so that any correspondence is updated and arrives at the correct address.

The use case of changing personal information contains logic which is specific for the use case, such as what page to display next. This logic should not be mixed according to the clean architecture with logic in the interface layer. Rules which reside in the interface layer are for example when a conditional Presentation style is applied. In this example we want to apply a conditional presentation style which indicates what steps are still to come in the process of changing the personal information. Depending on what has changed in the personal information, certain steps may not be applicable. Changing and address may be significantly easier compared to changing a name, and may need less steps.

Solutions

Do nothing

As this example is relatively straightforward, the option of not decoupling is certainly valid. There are usually not many rules placed in the interface layer, so it is a rather thin layer. The conditional presentation style would hold use case specific logic regarding what step is applicable.

Supporting attribute

A boolean attribute can be created to hold the logic when a step is applicable. The conditional presentation style then only needs to refer to the boolean attribute. In this manner the attribute belongs to the application layer, and conditional presentation style to the interface layer.

The first pattern which comes to mind for decoupling is Decoupling Pattern 1: Module with Flow. This is however rather difficult to do within Blueriq, as the pages and flow belong to the applications layer, while only part of the page belongs in the interface layer, the (conditional) presentation style.

Issues and considerations

In this situation it is advised to use a supporting attribute. This not only separates the concerns in your model, it also helps in debugging, testing and maintaining the application. If the business rules become complex, features such as the decision requirements graph are a greater supporting feature when an attribute is used.