176
Views
11
Comments
Solved
[Discovery] Can weak dependencies cause violations?
Question
Forge component by Francisco Menezes
110
Published on 23 Aug 2020

According to the outsystems documentation Screens, Service Actions and Structures are weak dependencies

https://success.outsystems.com/Documentation/11/Developing_an_Application/Reuse_and_Refactor/Understand_Strong_and_Weak_Dependencies

We are on version 5.0.7 of Discovery so I wouldn’t expect weak dependencies (such as screens and service actions) to be considered as violations. 

As mentioned in the release notes of version 5.0.6,  .. “Reviewed the cyclic references: now screens don’t raise this issue but entities and structures continue to raise.” …

Screens indeed don’t show violations, but Service Actions and Structures still do.

(In the module My_Lib I made a reference to a screen from the module My_Test and in the module My_Test I made a reference to a service action and a structure from the module My_CS) bu as shown in the below screenshot, I still see them as a violation.  Is there any explanation for this?


What is also confusing that when I look on the ‘Module canvas’ there is no violation for the dependency related to screens, but when I go to Modules > eSpace cycles than I get warnings about cyclic dependencies.


Staff
Rank: #274
Solution

Hi,

If those weak references are upper references then it is an architecture finding (previous terminology was violations), except when the modules are in different domains (eg. a _BL consuming an _API in another domain).

The reason why it is a finding is because conceptually it is wrong. Having a foundation module, that by nature is business agnostic, consuming a core module that is business related, creates a dependency into a non-business concept that could be later on consumed by another totally different concept. The higher you go in the canvas layers the higher business composition you will have. So even though you don't have publish impacts, you will have eventually deployment impacts in terms of application and/or module lifecycle.

Cyclic references even if weak are findings, for the same reason. You are conceptually tightening two modules. The only exception for this is between domains.

Please take a look on the attached PDF.

Hope this helps.

Discovery2.0moduleFindings.pdf

mvp_badge
MVP
Rank: #14

Hi,


I am tempted to say yes, because even if they are weak, you should not have references upwards.

It will impact deployments anyways.


mvp_badge
MVP
Rank: #105

I have two modules from different core applications referencing each other, X consuming an entity from Y and Y consuming a service action from X, and Discovery raises a cyclic reference between them. So I don't believe that Discovery is considering service actions as weak dependencies, but it should. 

Would be nice to have a feedback about this matter.  

Staff
Rank: #274
Solution

Hi,

If those weak references are upper references then it is an architecture finding (previous terminology was violations), except when the modules are in different domains (eg. a _BL consuming an _API in another domain).

The reason why it is a finding is because conceptually it is wrong. Having a foundation module, that by nature is business agnostic, consuming a core module that is business related, creates a dependency into a non-business concept that could be later on consumed by another totally different concept. The higher you go in the canvas layers the higher business composition you will have. So even though you don't have publish impacts, you will have eventually deployment impacts in terms of application and/or module lifecycle.

Cyclic references even if weak are findings, for the same reason. You are conceptually tightening two modules. The only exception for this is between domains.

Please take a look on the attached PDF.

Hope this helps.

Discovery2.0moduleFindings.pdf

Rank: #328

Hi,

As per my understanding though the dependencies are weak but if it leads to the circular dependency then you should resolve this as this is not the best practice and again your modules wont be updated in that case.

As per the solutions suggested if you have any kind of server action or service which is being used in multiple modules then separate it into common module are reuse as per the requirement.


Regards,

Swapnil

mvp_badge
MVP
Rank: #7

One of the major purposes of weak references is to allow for cyclic dependencies. As a programmer, I am *horrified* by cyclic dependencies, regardless if they are weak or not. But they are the only way to do things like having a theme contain a menu that refers to screens that use the theme... or to send an email from a core module when the email is in a module that depends on the core module sending the email...

Bottom line: Discovery needs to stop flagging weak references causing cyclic dependencies, it's why they are there in the first place.

J.Ja

Staff
Rank: #274

Hi Justin,

This was part of an internal reflection, and there are patterns to overcome the challenges you mentioned without creating cyclic or upper references. 

Please allow me to disagree with you when you state the bottom line, because weak references were created to optimize the publish and deployment processes and not to allow cyclic references. In the previous version Discovery wasn't validation all the rules OutSystems has in the Architecture Canvas, which now is.

Regards,

Davide


mvp_badge
MVP
Rank: #7

Davide -

The message I have been given by project management on an extremely frequent basis is contrary; I've been told quite clearly when I have said, "I don't want cyclic references at all in my projects" and "OutSystems has a real challenge with things like sending emails from core modules and themes linking to screens" that the answer was "just do it, it's fine because it is weak references".

Again, I personally think that is the wrong answer, as you do, but this is the answer I have been given many times by product management through the MVP Slack channels.

J.Ja

Staff
Rank: #274

Thank you Justin for the open feedback! I really appreciate it, since it is field feedback so valuable to us!

Staff
Rank: #70

Regarding this topic, we have updated the 4 LC architecture documentation recently.

With OutSystems 11 some strong dependencies were converted into weak dependencies (one of the strong dependencies that became weak dependencies is Screens), so it really depends on the platform versions, I don't know how feasible would be to change Discovery to take this into consideration.

Discovery is a visual tool to help analyze, measure and understand how to improve your factory architecture. This being said IMHO validations around weak dependencies should be in place and shown as violations. Is for you to judge if violation is somehow ok, if you want to live with, or if there is anything that you may improve and measure the effort needed to fix it.

I am one of those that can live with cyclic dependencies, if there is one justification, if you know the impacts and aware of the risks and you know how to deal with it, why not? Is a project management/factory management decision. I have seen many bad decisions to remove violations and the workaround implemented causes more issues than the one that it solves (there should be more reasons for changing your application code, just because there is one orange alert in one tool should not be the only reason).


mvp_badge
MVP
Rank: #7

"4 LC"? We got that fourth layer back again? :D

All joking aside... the reason why This Matters So Much is because teams are driving so much decision making not around "what makes sense in this situation?" but blindly following Discovery and Architecture Dashboard. And as you say, they then make very bad decisions because the tool said "violation" or "warning" or "finding".

Unfortunately, the message clients are hearing from OutSystems (regardless if this was the message OutSystems means to send) is: "if your code isn't getting 0 findings, it's bad code." I keep getting put into boxes where I am forced to defend perfectly fine code because the tool said "shame shame shame". I'm frustrated.

J.Ja

mvp_badge
MVP
Rank: #105

I agree with Justin 100%. Discovery, like the Architecture Dashboard, are tools that help to promote the applications architecture health. Showing a weak dependencies as a cyclical reference, in my honest opinion, in most scenarios generates just one more false positive. This makes the architecture validation confusing, by giving the false impression that there are strong dependencies violation problems. There is no way to distinguish both scenarios in Discovery tool.

Cyclical references, regardless of whether they are strong or not, should be avoided... agree with that too. However, there should be an option to ignore the findings for weak dependencies. In some scenarios, like Justin mentioned, it would be very useful.