Log in to AnswerLog in to Follow
2019-09-26 22-50-59
Rui Félix
4923Views
12Comments
[Cheat Sheet] OutSystems Module Naming Convention
Discussion
Best Practices
How-to

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.



55
0
16 Apr 2020

Thank you Rui

0
1
17 Apr 2020

Rui Félix wrote:

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.




Thank you for sharing

0
1
17 Apr 2020

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

1
0
04 Jun 2020

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?



5
0
05 Jun 2020

Hi, Tiago. His answer was very clear. Thank you.  

0
0
05 Jun 2020

Thank you for sharing

Regards

0
0
20 Jun 2020

I'm going to start using this ASAP.. Thanks friend.

1
0
08 Feb 2022

Very nice list, :)  Going to use it from now on :D

0
0
05 Jul 2022

Hi,


What about a BL for client side in Web reactive? It's equivalent to a MBL but it's not mobile.

0
0
30 Nov 2022

Naming convection of modules in out system


0
1
26 Jun

Thank you for sharing..

0
1
25 Jul

Standard best practices:  https://success.outsystems.com/documentation/best_practices/development/outsystems_platform_best_practices/

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