Skip to main content

Loosely coupling modules


Loosely coupling modules

When validating your architecture, most of the architecture violations are solved by moving elements from one module to another, in order to correctly isolate and abstract reusable services.

However, some unwanted relations between modules can’t be solved by moving elements around, as the elements are already in the right place. Loosely coupling the modules is the solution to solve these situations. The typical scenarios are the following:

Referencing screens from other modules

Don’t use screen destinations on upward references (like a Menu Web Block pointing to the entry points) and side references among End-User modules (like a link in a customer detail screen pointing to one of his loans in a different End-User module).

Use external URLs instead.

Reacting to business events

In this scenario, Contract_CS needs to consume Customer_CS since, conceptually, a contract relates to a customer.

The opposite relation is not desirable. Customer_CS should be independent of Contract_CS. In addition to creating a cyclic relation, not all consumers of Customer_CS need to depend on Contract_CS.

In this example, the incorrect relation is caused by the fact that a contract needs to be updated when the customer classification changes. Contract_CS is actually providing a callback that needs to be called when Customer_CS updates a customer.

There are two possible solutions:

  • Implement such callbacks using REST or SOAP web services. The strong dependency is relaxed. However, the logical dependency persists.
  • The recommended solution is to include a Customer_Event entity in Customer_CS, exposing BPT events. When a customer is updated, a new event with the Customer_Id is added. Customer_CS does not need to know who will be listening to that event, keeping its isolation. Contract_CS can have an automatic process reacting to such event. 

More information

To learn more about how to design your application architecture check the Designing the architecture of your OutSystems applications guide.

You can also check additional patterns to get further recommendations for your OutSystems architecture design.

  • Was this article helpful?