Hi All,
I recently completed the architecure self training and refered the documentation too
I have a question on designing an architecure canvas.
Considering a sample use case: Develop a order app with data migration from sql db to Outsystems database (Order entity), with SharePoint integration to store documents and consume a product entity from another service application which would contain relationship as below.
As per the above use case would the below architecure canvas is placed correct.
Question 1: Products_CS - As this is a different application and consumed in order application to get products information, so should that be part of foundation module
Question 2: SharePoint_IS is another service application has its own server actions to create folders, attach file & get file, should we need to have Core business logic module, since Order_CW and SharePoint_IS has direct integration to end user layer
Question 3: Order_BL has a dependency of Order_CS & Product_CS, since Product_CS is an another application does it have any impact
Hey there Sudharshan,
1) No.
Foundations modules are reusable services for non-functional requirements. This applies to forge components, plugins, libraries, integrations with external systems, themes and so on. Products_CS is a module with entities and business information. As such, it is considered as a Core Module even if it's consumed by a different app.
2) No.
You don't need to have it, meaning it's not mandatory. There's only one downward reference so your architecture is good to go. Also it is already a Core Module (Orders_CW) that is calling Sharepoint_IS. And Sharepoint_IS is in another different application, which is correct. This way you'll be able to reuse it across multiple apps. You may have a Sharepoint_BL module if you have additional logic.
3) Depends.
Are you talking about another business application or another OutSystems application?
In the end of the day, an OutSystems application is like a folder where you can group modules. One business application is composed by one or more OutSystems applications, each one of them with one or more modules & extensions.
Does this second application have only this Product_CS module in it or other modules as well? UI modules, IS modules? Is this second application a business application? That's the key for your question.
If your second application is a business application, then yes, you will have problems. Because you'll create a direct dependency between two different business apps. Different business apps usually have different requirements and lifecycles, and this dependency will be challenging for example during deploys, like mentioned above.
But if your second application is just an OutSystems app with this module Product_CS isolated in it, then there's a whole new story. Product_CS simply being in another OutSystems application has nothing wrong with it. And it can make perfect sense to be isolated if it's reused for several other modules.
Your major concern when isolating Product_CS into another OutSystems app should be the fact that you'll create a cyclic reference between both apps.
Orders_BL (App 1) -> Products_CS (App 2)
Products_CS (App 2) -> Orders_CS (App 1)
Even though the dependencies between modules are ok at first sight, you'll end up with a cyclic dependency between applications, which is something you should avoid.
Please check this documentation for extra information regarding this, I'm sure it will help you!
Kind regards,
Rui Barradas
Hi @Rui Barradas , Thank you for inputs
Question: 2 - Wouldn't that be tightly coupled between SharePoint_IS and Order_CW. Can we Add a "SharePoint_BL" in Core Logic of Order App to wrap SharePoint_IS actions & logics.
Question: 3 - Considering that Products is a dedicated Service application containing only the Products_CS module, we need to consume it in two places within the Order application:
How can we avoid creating a cyclic reference between the Order application and the Products service application?
Hi @Sudharshan T ,
Question 2 Answer:
Yes. By adding a SharePoint_BL core logic module is a good architectural move. It decouples your UI (Order_CW) from the external integration (SharePoint_IS) and ensures better abstraction, reusability and easy to maintenance.
Question 3 Answer:
To keep Products_CS purely as a service module without referencing any Order app modules.
Consume Products_CS directly in both Order_BL for logic and Order_CW for UI without letting either module reference back into the Products app.
If reusable logic is needed for both UI and BL, consider abstracting it in a shared Core module within the Order app.
More details: https://success.outsystems.com/documentation/11/app_architecture/designing_the_architecture_of_your_outsystems_applications/application_composition/applying_the_architecture_canvas_to_applications/
Hello Sudharshan,
About question 2, having a dependency between Orders_CW and Sharepoint_IS has nothing wrong with it by itself. It's not an architecture violation.
About having a Sharepoint_BL, you asked if you need to, I replied that it is not mandatory, meaning you are not forced to have it. But it can make sense.
Sharepoint_IS will have the integrations with external systems and wrappers for those integrations. If you don't have additional logic, why do you need a Sharepoint_BL? It would be a wrapper from a wrapper. But if you do have additional logic, then it makes total sense to have a Sharepoint_BL.
Let's say you need an action to create a folder and attach a file in the same flow or process, this logic should be in Sharepoint_BL.
In any case, Sharepoint_BL should be in the same application with Sharepoint_IS.
About question 3, you mentioned you need to consume Products_CS in Order_BL and Order_CW. There's nothing wrong with it since Orders app is consuming Products app.
But in your architecture design, you mentioned that Products_CS also need to consume Orders_CS:
This is the dependency that will cause the cyclic reference and that you should avoid. Why do you need this dependency?
Thanks @Rui Barradas and @Sriyamini , I'm cleared with question 2
Question 3: Let's take i need to capture productid while filling the order form, so Order_CW would contain a block with form as below - Order_CW would have dependancy of both Order_CS and Product_CS - To capture the input and create orders. Note: I'm not going to manage (i.e. Create, Update or Delete operations) products list from Order app. Its is used to get or read the products as a list for dropdown
@Sudharshan T
For Question 3, I suggest reading Rule #3 in https://success.outsystems.com/documentation/11/app_architecture/designing_the_architecture_of_your_outsystems_applications/validating_your_application_architecture/.
There is a tip "However, If A and B are too strongly coupled, they should be merged together. ", which is likely to be your situation, so you may evaluate if Product_CS and Order_CS can be combined.
Hello again Sudharshan,
So as far as I understood from your explanation, Orders_CS is consuming Products_CS, and not the opposite as you described in your image. Meaning Products_CS is not consuming Orders_CS. Can you confirm this?
According to your last description, you'll have this:
- Orders_CW (Orders App) is a consumer of Products_CS (Products App)
- Orders_BL (Orders App) is a consumer of Products_CS (Products App)
- Orders_CS (Orders App) is a consumer of Products_CS (Products App)
- Products_CS (Products App) is not a consumer of Orders_CS or any other module from Orders App
If that's the case, only Orders App consumes Products App, and not the other way around. Therefore, you don't have a cyclic reference, so you are good to go. There's nothing wrong with your architecture.
Just a small thing:
You should review this arrow (marked on red) on your diagram and change the direction of it, because it seems that Products_CS is a consumer of Orders_CS. This would cause the cyclic reference.
Hi @Rui Barradas ,
Products_CS is not consuming Orders_CS or any other module within Order App.
Ok, then you don’t have a cyclic reference.
It was just the arrow on the diagram that is in the wrong direction and lead me into considering that.
But the important thing is, your architecture is good to go.
I hope that all of your questions are answered. Let me know if you have any extra questions or concerns.
Thanks @Rui Barradas for all your inputs and verifying the canvas.
1. Yes, Foundation modules are built for reuse across multiple apps. but also you can split the share entities in common module both of them use it
2. Yes, ideally you should introduce a Core business logic module to act as a middle layer between the End-User layer and service integrations like Order_CW and SharePoint_IS.
3. Yes, it can have an impact. Since Product_CS belongs to another application, Order_BL now depends on external logic. This cross-application dependency increases coupling, which can lead to deployment and maintenance challenges. Ideally, shared components like Product_CS should be in a Core Service module designed for reuse across apps.
I hope I was clear. If anything isn’t clear, feel free to reach out to me anytime.