[Cheat Sheet] OutSystems Module Naming Convention

Rui Félix

Discussion

Since this information is only available on the course video located here, and I can't post on the [Hint and How to] forum, I'm adding there this quick reference sheet for the naming convention of OutSystems Modules.

FOUNDATION MODULES

_Lib: Generic Library module.
_IS: Integration Services - technical wrapper to consume and normalize an external service.
_Drv: Driver module - to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern).
_Th: Theme, look & feel elements, menu, etc.
_Pat: Reusable UI Patterns for layout and display only - no Business logic.

CORE MODULES

_CS*: Reusable Core Services with public entities, actions, and blocks.
_BL*, _CW*: Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle.
_Eng: A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions.
_Sync: Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system.
_API: Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.

*Add a “M” for a Mobile module, like _MCS, _MBL or _MCW.

16 Apr 2020

Rahul

MVP

Thank you Rui

17 Apr 2020

Salman Ansari

Rui Félix wrote:

FOUNDATION MODULES

_Lib: Generic Library module.
_IS: Integration Services - technical wrapper to consume and normalize an external service.
_Drv: Driver module - to have several integration services with different systems, performing the same type of operation (e.g. printers) you can create several drivers exposing the same API, with specialized implementations (like the transparency services pattern).
_Th: Theme, look & feel elements, menu, etc.
_Pat: Reusable UI Patterns for layout and display only - no Business logic.

CORE MODULES

_CS*: Reusable Core Services with public entities, actions, and blocks.
_BL*, _CW*: Isolated Business Logic (Actions) or Core Widgets (blocks), to manage complexity, composition or to have its own lifecycle.
_Eng: A BL becomes a Calculation Engine if it performs complex calculations, (e.g. an invoice calculation engine or an insurance simulator). Engines are usually subject to versions.
_Sync: Logic to Synchronize data in CS's with an external system. Isolating this logic makes the CS completely system agnostic and it’s easier to decouple or replace the external system.
_API: Technical wrapper to expose an API to External consumers, keeping core services system agnostic and supporting multiple versions of the API.

*Add a “M” for a Mobile module, like _MCS, _MBL or _MCW.

Thank you for sharing

17 Apr 2020

Joel Lobo

Can I use a specific extension for the Orchestration Layer and End User Layer modules?

04 Jun 2020

1 reply

05 Jun 2020

Show thread

Hide thread

Tiago Bernardo

Champion

Hi Joel,

First, Orchestration Layer should be considered as being discontinued (although it still appears in documentation) as it does not make sense to exist anymore because Screens/Links/URLs are now considered weak dependencies. The main purpose for the Orchestration Layer to exist was to avoid having side references between modules in the End User Layer (Validating your application architecture).

Second, for the End User Layer you can use a specific naming convention, like using the suffix "_UI", but it is not a common case to use it, because you have to remember that for UI modules the end-user will see the name of the module in the URL, so it will be strange, although still usable.

As an example, if the main module of your application is named "MyApp_UI" (using the naming convention of a suffix "_UI"), that would be name the name that your users would have to enter to access your application, which is a bit strange. Better would just be "MyApp".

As a final remark, if you use naming conventions for the End User Layer modules, you can use SEO Friendly URLs to make URLs easier for end-users and also promote Search Engine Optimization (SEO).

--Tiago Bernardo

Joel Lobo wrote:

Can I use a specific extension for the Orchestration Layer and End User Layer modules?

05 Jun 2020