Implicit relationships were a good thing and should not have been removed

[jerkstorecaller]

Description

Can you please revert or rethink the solution to #166? If you think about it from the perspective of casual users only interested in producing nice doc with as little effort as possible, this breaking change is bad. It costs the user convenience and utility, for no benefit that I can perceive. Please explain, how does a single dynamic view creating relationships make anything confusing or worse?

I have a single "bird's eye view of everything" dynamic animation I wrote to help people understand a full end-to-end flow of my multi-system project. In an animation like that, I don't want to show components that only act as a middle-man (i.e. implementation details) even though they exist, because there's already way too much going on on the screen.

Now my options are:

1. Make these relationship explicitly defined in the model. Now a dev looking at that system in isolation will see two relationships, The real world Entity1 -> Middleman -> Entity2, and the new Entity1 -> Entity2, just because I want my animation to show Entity1 -> Entity2.
2. Delete my "bird's eye" view, never write views like that again

Option 1 is obviously unacceptable, leaving only option 2. Structurizr's utility just got slashed.

There should be a "casual_mode" directive that leaves all the convenience that ordinary people would depend on. My recommendation is to never remove features that give convenience, just hide them behind this flag.

Priority

Low

Resolution

I have no budget, please add this feature for free

More information

No response

[simonbrowndotje]

Please explain, how does a single dynamic view creating relationships make anything confusing or worse?

As @dgutson said in #166 ... having the model modified from a view definition was not consistent with the rest of the tooling - views should only be views onto the model, and not modify the model itself.

[sirhaug]

I'm with @jerkstorecaller on this one, and I'm sad to see that implicit relationships will not return.

Our team made the decision to migrate away from Structurizr because of this change. (There were other factors as well, but this is the one that "broke us".)

We used Structurizr "casually" to keep a decent overwiew of our architecture and to make a handful of diagrams/views of our most vital functionality. Removing implicit relationships made it harder for us to keep these simple views, and so we have decided to ditch them entirely.

[simonbrowndotje]

I'm sad to see that implicit relationships will not return

1. These relationships were never "implicit". The feature that was removed allowed relationships to be added to the model from a dynamic view definition ... which is at odds with the rest of the DSL and how it works.
2. Adding relationships from a dynamic view definition can cause some unexpected side-effects when used in conjunction with implied relationships (a feature that still exists).

We used Structurizr "casually"

The C4 model, and therefore Structurizr, is designed to add some precision to the way teams think about, discuss, and describe their software architectures. Structurizr in particular isn't designed for "casual use", in the same way a diagramming tool is. Anyway, I hope you found something more suitable.

[dgutson]

Our whole architecture definition process (not only tooling) is around C4 as a methodology and structurizr as a tool, moreover, we built a toolchain around it (including a compiler, two plugins, and a plantUML validator that checks consistency with the C4 model). We leverage the "architecture as code" approach to turn architecture reviews as PRs in the regular review process. We plan to add a rules-based architecture linter (checking clean architecture properties among others) to the CI pipeline in order to ensure that the architecture PR will meet quality baselines. We spent tons of engineering hours in this system.
If you use structurizr as a casual tool, you are missong the most important points of this system as a game changer paradigm.