Refactoring method for module "integration" rather than isolate them.
Service Studio Version
11.10.10 (Build 38781)


As a refactoring practice in OutSystems

I watched the technique of module isolation (e.g. extracting CS) in the Learning video.

What I want to know now is a refactoring technique that integrates multiple modules.

As the stack of dependencies grew, I faced the need to resolve chained outdated and the resulting Runtime Error.

Therefore, the ones with little merit of being separated

What can be integrated one step further is the intention to reduce management complexity by integrating.

Thenk you.


Hi Takeda San

From what I understand, if it's just one app, there's not much point in separating the modules. However, if you have multiple apps and common functions, you need to create a common module to separate the common parts, otherwise, it will be difficult to manage dependencies.

This is just my opinion, so it may be wrong. Hope someone has more correct answer for this.

Kind regard

Hi Takeda,

    First you need to separate your all module with UI

layer and DATA layer.  and make sure there is no cyclic dependency between module you can check cyclic dependency by using DISCOVERY tool.


Cv sharma

Mr. Zhao
Mr. Sharma

Thank you for your reply.

For example, for base layer modules, for A and B
If the configuration is A <-B (B consumes A),
We have to republish B when you update A and republish B's consumers.

If I realize that A and B are not the particles that should be separated, I would like to do so because it saves the above-mentioned effort if the two are integrated (for example, B is weak module).

I would be grateful if that could be achieved in a simple way.


Hi Takeda San

If I understand you right, You are looking for weak dependencies.

In Outsystems11 they introduced a new action type called Service Action. 

It can achieve weak dependency.

Please refer to these links below

Kind regard


One can not just use service actions to try and have less outdated references. Service actions have several important consequences.

First of all the are rest calls under the hood so slower then calling a server action. 

Second they create a separate, additional connection, causing the need for extra exception handling logic to many rollback scenarios of distributed transaction.

Service actions should be used especially to decouple different domains.


Hello Eiji,

If all of A is only consumed by B, and you don't to see that changing any time soon, I see no reason why you could not merge all of A into B. 

Don't make your factory unnecessary over fragmented with lots of small modules that do very little.

Separation of concepts, independent life cycle or size of module should be reasons to keep the modules separated. 

For example an End user modukeand a separate module with a lot of resources (images etc) consumed only by that End User module.

In this case although strongly related keep the resources separate. They don't change a lot and moving those elements in the end user module will cause slower 1CP and bigger oml versions stored in your database metamodel.



Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.