Hi,
I am new to Outsystems and trying to understand the architecture design.
I want to know why can't we have side references in end user module? why can't we have cyclic dependencies and downward dependencies?
Is it because only to keep our application organized and maintain our application performance and speed of interaction?
Hi Shreelakshmi,
"To ensure that your architecture is sound and that you don’t end up with either a monolith or a spaghetti architecture, you should follow a set of guidelines and recommendations."
As for the mentioned queries, I would suggest you refer to this well-documented Blog Post for better understanding (I don't want to miss any points in my explanation)
https://www.outsystems.com/blog/posts/application-architecture/
Kind regards,
Benjith Sam
Thanks Benjith Sam.. :) It helped me to understand better
Consider taking a look at this lesson on Validating an Architecture.
It will answer all your questions on this topic in a clear manner, but to add more detail to your original question "Why can't we have side reference in End user module", consider the below screenshot from the video:
In the above example, when you change something on the right bottom green foundation, you will have to republish all right-side core modules, EU2 and EU1. Specially, if you have a team working on the EU2 application and all the below modules and they want to deploy it in Production, you may end up having to take EU1 application as well.
This accounts for:
Hope it helps.
Regards,João
Thanks João.. :) It helped me to understand better
Hi João,
To clarify my understanding of this sideways dependency and why it is such a bad thing, if a core or foundation module of EU2 was changed and then needed to be republished up the tree, would EU1 not only need to be republished (and possibly deployed if EU2 is deployed) if one of the changes to EU2's lower modules directly impacted what EU1 it is consuming of EU2?
e.g. say a Server Action inside a core of EU2 was changed and thus EU2 needed to be republished as a result, but EU1 does not consume an action of EU2 that used this core server action and thus it sees no change. Then I would think EU1 would not need to be republished or deployed.
I will look at the block post mentioned above, but do you have a similar explanation of why Circular dependencies are also not allowed - I see lots of documentation saying they are bad and cause monoliths (like this sideways dependency) but not the WHY behind this if that makes sense... I like to fully understand and not just accept it as a rule with no WHY...
Has Orchestration layer been removed from Outsystems 11 version?
If Yes, why?
Hi Shreelakshmi N S
Yes, the Orchestration layer has been removed from Outsystems 11.
https://success.outsystems.com/Support/Enterprise_Customers/Maintenance_and_Operations/Designing_the_Architecture_of_Your_OutSystems_Applications/The_Architecture_Canvas
Regards
Hello.
Like it is stated on the videos above the fourth layer was for linking purposes between third layer modules. The thing is, those links are for pages, not for actions. It is very hard for them to be outdated and if you play with Entry Points and SEO Rules you can fix any error that may appear. Therefore such dependencies are called weak dependencies.
By seeing that an extra layer was used to handle a weak dependency, the model was simplified to having only 3, and weak links are not considered a dependency now.
Keep It Simple.
Hi @Nuno Reis, sorry this is an old thread, but I was exploring the weak dependencies and having these doubts:
- Can we say all the reference rules (side, upward and cyclic) are for strong dependencies only and can be ignored in case of weak dependencies i.e. for screen, entities, service actions etc?
- While in lesson "Refactoring an application", it is suggested as below which was little different from what I have been reading that 'screen dependencies are ok at least in case of side references in end user modules' but here it is mentioned to avoid it even for side reference. So, can I assume that it is mentioned as part of best practice but still it will not be violating the rules? Thanks
If you are referring to this video, it starts by saying 4 layer canvas so yes, it is old.
The top layer was removed when weak dependencies showed up. In dependencies, you need to keep updated references so any change on the original element is known to all consumers. Digging into more detail:
Side references: they are ok - you can publish in a specific order - but it is the start of things going the wrong way.
Cyclic references: If two modules are mutual consumers, you can't have them updated unless you publish them at the same time. Not a great rule to share with other teams...
Upward references: OutSystems is fast. It takes you to the highway of development. And you are driving in the opposite direction. Just don't.
Yet, the upward reference was the most common scenario in unsupervised developers. You have the Theme at the bottom layer, need to link to End User modules on the top layer... But looking at the explanation I wrote above "you need to keep updated references so any change on the original element is known to all consumers". A page has no "return" or deprecated logic. They have no output. The moment you follow a link to a screen, you switch to that screen/module/application and nothing of what you are doing there will be affected by a deprecated version. Worst case scenario is that you passed wrong parameters in the URL.
That is considered not critical (weak dependence) and you are free to do it. The explanation is 3 sentences long in the documentation.
So yes, consider those rules for strong dependencies only, but try to apply them whenever you can (A good architect at the start of the project can make a big difference)
Thank you @Nuno Reis for the great explanation. I did not notice it is talking in context of 4 layers architecture. Also, I understood that upward reference of screen is no longer an issue in the new 3 layers architecture. Consumer of screen does not need to know the content/implementation of the screen as browser will be loading the content directly from the URL. So, it is ok to have it.
Lastly, I also agree with the fact that we should take care of rules as long as possible whether it is strong or weak dependency. Thank you so much again!
Sorry I noticed typo in my above comment. Instead of upward, I meant "side" reference in the line "upward reference of screen is no longer an issue in the new 3 layers architecture ".