[DSL] A relationship between ... already exists, property to ignore this

[neopaf]

Description

Two different people create two separate systems in two different git repos.

They both define that they communicate:

• Architect of A defines that A->B "action".
• Architect of B defines that A->B "action" (action is the same, obviously).

When I include both dsl files into my space to give readers an overview of all systems of my department, dear Structurizr complains of a (complete) duplicate.

Please consider a property to ignore these conflicts: say, ignoreDuplicateRelationships, default false.

Then each A and B architects could have errors in case they have local conflicts.
But for overall picture one could turn ignoreDuplicateRelationships=true and be happy?

Priority

I have no budget and there's no rush, please add this feature for free

More information

(thanks for AWESOME product!)

[simonbrowndotje]

This is working as designed, and I'd rather not start adding flags to disable various validation rules. You're welcome to add that functionality to your own fork though.

I'd recommend looking at the enterprise examples that show a better way to generate landscape view of a collection of systems.

[neopaf]

thanks for the pointer, Simon.
Alas, I can't find the landscape view here.
We wanted an overall schema, navigable down into all the systems and their internals.

All that stops us (as we see it) is extra validation, that just gets in the way of our happiness.

[simonbrowndotje]

Alas, I can't find the landscape view here.
We wanted an overall schema, navigable down into all the systems and their internals.

That's exactly what the demo does. Did you run it?

[neopaf]

I did, and I see separate systems, all full of internal life. Yet without links between softwareSystems.
As I'm trying to communicate is that we have different architects of all these systems and each of them wants to show softwareSystem(his)<->softwareSystem(external) relationships.

Running example1:

[simonbrowndotje]

You need to run it using the instructions at https://github.com/structurizr/examples/tree/main/enterprise#example-1 rather than using Structurizr Lite.

./gradlew run -PmainClass=org.example.Example1

[neopaf]

Hmm. Thanks for pointing that out, Simon.
Alas, we're dreaming of something DSL only, maybe with a sprinkle of scripts....

Do you think it's possible to somehow script-create whatever example1 code does?
enrichSystemLandscape and findAndCloneRelationships in scripts?

[neopaf]

With these parts of the whole, where, say, this relationship

            webapp -> customerService "Manages customer data using" "JSON/HTTPS"

is mentioned only once -- we can include all the .dsl files into one master file.
And get all the relations displayed.

But then only the architect that created that relationship would see it -- others, in this example, CustomerService architect would not see it on diagrams that he/she creates, when he/she plays in local Structurizr instance.

[simonbrowndotje]

Do you think it's possible to somehow script-create whatever example1 code does?
enrichSystemLandscape and findAndCloneRelationships in scripts?

It should be, yes.

[neopaf]

I'm at a loss as to how to do that: how to come over the fact that A->B relationship exists in both pieces?
Looks like one needs to load spaces from workspace script rather than trying to include them into master-workspace .dsl, as I've tried originally.

Not sure how to do that from scripts. Any pointers, Simon?

[neopaf]

Do you think it's possible to somehow script-create whatever example1 code does?
enrichSystemLandscape and findAndCloneRelationships in scripts?

It should be, yes.

Doesn't seem to be possible.
Structurizr Lite shows only 1 workspace at http://localhost:8080/workspace, even if I'd figure out how to add newly generated Workspace instance to some internal list (couldn't yet).

Maybe On-Premises could do that: execute script after loading something that would create/update some other workspace.
But this all seems cumbersome, and sub part relative to what you've suggested earlier.