We are trying to divide our applications into different domains and we identify trespassers across domain boundaries using Discovery. But the only way Discovery is useful here is the actual domain level, so pressing the sideward pointing arrow in the domain page is giving us good information
But when we go to applications, we see the following:
So this application is in domain A, and apparently it has two references to a different domain. Seems ok, but the popup is giving us (for example) this:
Now when I check the usage of each of these server actions they are only used in their own domain and NOT in the domain we have selected here at all. Around 90% of the so-called "tresspasses" are not tresspasses at all. This makes it really hard to identify what actually needs to be fixed.
Can you please fix this?
I think I found the culprit. There are two aggregates in the preparation of page "Warnings" (in flow ApplicationCanvasFlow) that are simply not using the inputparameter ApplicationDefId in their filter, which results in a large list for all trespassed modules/elements, and not just the ones trespassed by the selected application.
So the aggregate GetDomainReferenceModules (which is responsible for the list of modules in the popup) now has an extra filter in our customized version:
And so does the aggregate GetDomainReferencesNamed (which is responsible for the list of elements):
Now we only see the trespassers for the selected application.
Can you please implement this in the Forge version?
One extra thing I did not fix because it's a lot more work is the server actions in DiscoveryProbe that return the count values in the labels. None of them have a TargetApplicationDefId, so it seems to me that the numbers are always on domain level no matter what application you choose?
It's true that a ServiceAction is a weak reference, and it should not be captured in that scenario (as a principle). But when you are referencing or consuming ServerActions we highlight weak references, if they exist, as well.
The goal to have those service actions shown is to help to you choose where you can move or wrap or encapsulate the consumed server actions.
The use case to show the service actions referenced whenever a strong references exist between Domains, it's only to give you a 360 vision and guide you. Giving you a path to reuse any service action already exposed, and if is not the case, create a new service action in another module, if the current doesn't make sense to support/expose the core business logic.
Having that said, we are always open to change this behavior, so we will analyze the potential solution to check if can be accommodated.
Thanks for your feedback.
I don't mean to be rude, but how is your answer related to this post? Because this is not about strong or weak references, and I never mentioned service actions at all.
This is about forgetting an important part of the filter in an aggregate.
The aggregates are showing modules / elements that are not even used in other domains at all (and are therefore not trespassed), simply because they are missing a filter that checks whether the current application is actually using the components (TargetApplicationDefId = ApplicationDefId)
Apologies for that. I was thinking that it was about the fact that service actions are shown on the warnings, even without being referenced.
We will look at that solution and apply it to the next version.