198
Views
7
Comments
Architecture Module CW, BL CS
Discussion

Hello,

I am here to share about how best to approach the relationship between CW, BL, CS, etc. modules.

So, I will do the development by doing this module approach

CW-> BL> CS


First scenario

CS: contains only non-public entities, and also public server actions, only CRUD actions, and data retrieval on public entities in the form of server actions, (such as FindEmployees, FindEmployeeById), 

BL: responsible for accessing data to be retrieved or processed, such as validation, checking roles, from this BL Module will produce an action (FindEmployee) that has been validated from input or roles, and is ready to be used in the CS module.

CW: is the place where the block is created along with the data that will be displayed from the BL module.


Second scenario

CS module performs a public Entity, with read only set, and creates a public server CRUD action without role validation, and

The BL module performs Consume Entity then creates a server action (FIndEmployee), and performs Consume CRUD action, and creates a new CRUD function in the BL module by adding validations such as role and mandatory input, to be ready for use in CW.


The third scenario

where the CS module, the public entity is read-only, remains a CRUD action, also validated directly, such as mandatory and role validations, in the CS module, after which it is made public.

and the BL module will consume the CS module.


why don't I use the CS module on CW?

because in the case that I experienced before, 

where there is a change in the filter on the data that must be displayed, so I have to replace or update the filter on each aggregate created at the screen level.


So with the approach of creating Action Data or data that has been wrapped in server actions, it is hoped that it can be reused and only replace one or several actions when there are additional filters or others so that each screen has adjusted.


The question is, which approach is best from the above cases or scenarios?

and when to use or place actions or components in CW module, BL module or CS Module?


Thank you very much


2024-12-02 13-16-47
Vipin Yadav

Hi Rijal RF,

The best approach among the scenarios depends on your need for modularization and security. Option for the second or third scenario if stronger role validation and data encapsulation are required. Use CW for UI components only and keep business logic and data access confined to BL and CS for clear separation of concerns. This method ensures easier updates and better reusability of server actions, especially when changes are required in the data filters.

Thanks,

Vipin Yadav

UserImage.jpg
Rijal RF

I would like to understand why the first scenario is not recommended. Could you please provide the reasons for it? I will try to understand it better.

Thank you again for your great suggestions!

2024-12-02 13-16-47
Vipin Yadav

In the first scenario, OutSystems modular architecture principles are not fully applied because CS should expose only essential public data or actions for reuse without specific business logic. Instead, data retrieval should occur in BL to maintain separation of concerns, ensuring that CS focuses on data access while BL manages validations and processing for CW.

Thanks,

Vipin Yadav 


2024-07-12 05-57-50
Gourav Shrivastava
Champion

The best approach depends on the complexity of your application:

  1. Scenario 1 (Recommended for Enterprise Applications):

    • CS: Non-public entities, CRUD actions only.
    • BL: Validations, role checks, and reusable server actions.
    • CW: Focuses on UI, consuming BL actions.
    • Why: Ensures clean separation of concerns, reusability, and easy maintenance.
  2. Scenario 2 (For Mid-Sized Applications):

    • CS: Public entities (read-only), CRUD actions without validations.
    • BL: Adds role checks, validations, and reusable CRUD logic.
    • CW: Consumes BL actions.
    • Why: Keeps CS lightweight while centralizing logic in BL.
  3. Scenario 3 (For Small Applications):

    • CS: Read-only entities, CRUD actions with validations.
    • BL: Simplified logic-consuming CS actions.
    • CW: Directly uses BL.
    • Why : Reduces layers for simple use cases but couples logic with CS.

Avoid using CS in CW to prevent scattered logic. Use BL to centralize data processing, so changes affect all screens consistently. Scenario 1 is the most maintainable for complex projects.

2021-09-06 15-09-53
Dorine Boudry
 
MVP

Hi @Gourav Shrivastava ,

I think for option 3, you meant to say 'directly uses CS' ? right ?

I think this is a very complete and nuanced answer, I personally think

  • it goes from a lot of work to very little work, and the difficulty is in deciding how heavy of an architecture to choose and also how to move an initial simple approach into a more intricate approach
  • I personally don't see any problem with referencing entities from CW at any size/complexity of application, I think you are talking only about consuming update actions or complex reusable queries, right ? you don't explicitly mention anything about using entity structures / aggregates / sql on entities from CW
  • I think that even in large complex systems, there is room for some validations on the CS level : anything that is directly related to the entity being changed and is always true (so not dependant on complex business rules and not dependant on other data), and anything that would hurt database integrity. 

Dorine

2024-07-12 05-57-50
Gourav Shrivastava
Champion

Hi @Dorine Boudry 

I agree that validations tied to database integrity or entity-level rules can be handled in CS. However, I focus on centralizing reusable queries or update actions in BL to avoid scattered logic and ensure easier maintenance, especially in complex systems.

Appreciate your insights!

Thanks

Regards Gourav Shrivastava

UserImage.jpg
Rijal RF

Thank you for the very helpful answer!


I have related doubts

Can public module_CS actions / entities be consumed by other Model_CS?

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