Hi,

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

It will impact deployments anyways.

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.  

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.

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

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

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

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

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).

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.