discussion: !identifiers hierarchical doesn't affect relationship identifiers

[aisamu]

Although the manual clearly points it out, the fact that relationship identifiers aren't hierarchical tripped us up today.

Is there a particular reason for that being so (other than not yet implemented, that is)?

Our use case is somewhat like the following:

workspace {

   !identifiers hierarchical

    model {
        user = person "User"
        
        system = softwareSystem "System" {
            subSystem = container "A sub-system"
            self = subSystem -> subSystem "bootstraps itself"
        }
        
        systemB = softwareSystem "System B" {
            subSystem = container "A sub-system"
            self = subSystem -> subSystem "bootstraps itself"
        }

        user -> system.subSystem "Uses"
    }

    views {
        dynamic system {
            system.self "bootstrapping step 1"
            system.self "bootstrapping step 2..."           
            systemB.self "bootstrapping step 1" 
            systemB.self "bootstrapping step 2..."
            properties {
              plantuml.sequenceDiagram true
            }
        }
    }
}

(Pardon for opening an issue, but the repository doesn't seem to have Discussions enabled.)

Thanks for writing structurizr - and sharing the cli with us!

[simonbrowndotje]

The short answer is that relationship identifiers are much less useful than they first appear, particularly given how the implied relationships functionality works, so I decided not to implement hierarchical relationship identifiers.

Having hierarchical relationship identifiers would perhaps also suggest that implied relationships are also identifiable. For example, given this:

workspace {

   !identifiers hierarchical

    model {
        a = softwareSystem "A" {
            aa = container "AA" {
                aaa = component "AAA"
            }
        }
        b = softwareSystem "B" {
            bb = container "BB" {
                rel = this -> a.aa.aaa
            }
        }
    }
}

Here, b.bb.rel represents a container (b.bb) to component (a.aa.aaa) relationship. And you could reasonably expect that b.rel might represent the implied software system (b) to component (a.aa.aaa) relationship. But then what about the implied container (b.bb) to container (a.aa) relationship, would that also be called b.bb.rel? It's all a bit complicated.

You're welcome to submit a proposal as to how this could work, but it would need to be backwards compatible with the current behaviour since this has been in the wild for 18+ months now.

[aisamu]

Thanks for the prompt response!

I'm not at all familiar with the implied relationship feature, so that might explain why I expected hierarchical relationship references to "just work".
As an example of my blissful ignorance, I would not even consider b.rel or b.bb.rel to be a thing!

You're welcome to submit a proposal as to how this could work

Given the above, I hope you realize how ill-advised this is 😂

[a] backwards compatible [proposal]

My naive expectation is to completely disregard implied relationships when dereferencing, as the identifier was explicitly set at a specific point.
Other than special anaphoric keywords (e.g. this, self), I'd probably be surprised by a "moving" identifier.
Even in languages where dynamic bindings are not unusual, they're usually "marked" (e.g. earmuffs) to reduce surprises.

Backwards compatibility would require it to be enabled under a separate flag (e.g.):

  !identifiers hierarchical hierarchical-relationships

[simonbrowndotje]

The problem with relationships is that you can define the same relationship in multiple places and they'll be functionally equivalent yet identifiable differently.

workspace {

   !identifiers hierarchical

    model {
        a = softwareSystem "A"

        b = softwareSystem "B" {
            rel = a -> this # b.rel
        }
        
        rel = a -> b # rel
    }
    
}

And I can imagine seeing issues (I have to support this), as to why rel can't be referenced as a.rel, because the relationship ultimately "belongs" to a. I'm not convinced I'm afraid, but we can leave this discussion open for a while to seek wider comments.

Changing the subject though, you may find the following dynamic view definition a little more verbose, but easier to understand more quickly:

workspace {

   !identifiers hierarchical

    model {
        user = person "User"
        
        system = softwareSystem "System" {
            subSystem = container "A sub-system"
            subSystem -> subSystem "bootstraps itself"
        }
        
        systemB = softwareSystem "System B" {
            subSystem = container "A sub-system"
            subSystem -> subSystem "bootstraps itself"
        }

        user -> system.subSystem "Uses"
    }

    views {
        dynamic system {
            system.subSystem -> system.subSystem "bootstrapping step 1"
            system.subSystem -> system.subSystem "bootstrapping step 2..."           
            systemB.subSystem -> systemB.subSystem "bootstrapping step 1" 
            systemB.subSystem -> systemB.subSystem "bootstrapping step 2..."
            properties {
              plantuml.sequenceDiagram true
            }
        }
    }
}

[aisamu]

why rel can't be referenced as a.rel, because the relationship ultimately "belongs" to a.

I suppose that's why I qualified my ignorance as "blissful" before: I honestly wouldn't even consider that to be a possibility, so it doesn't confuse me in the least.

you may find the following dynamic view definition a little more verbose, but easier to understand more quickly

I completely agree that explicitness is usually better than identifiers.
And, in the specific example above, the relationship I'm was trying to name there is a very particular one, and arguably universally applicable: self. By referring to that well known idea, we can be more explicit and specific without having to introduce a new concept.

Compared to system.subSystem.self, parsing system.subSystem -> system.subSystem has more cognitive load given both the mechanical aspect of more text and the and semantic aspect of significantly more possibilities.

To step out of the theoretical realm, the practical reason we decided to name the relationship was due to a typing mistake like the following:

            system.subSystem -> system.subSystem "bootstrapping step 1"
            system.subSystem -> systemB.subSystem "bootstrapping step 2..."           
            systemB.subSystem -> system.subSystem "bootstrapping step 1" 
            systemB.subSystem -> systemB.subSystem "bootstrapping step 2..."

i.e. lines 2 and 3 are incorrectly not pointing to self. That'd be just not possible if we were referencing the self relationship by a more explicit/specific pointer, so we went ahead and did that.

I honestly even reached out to self as if it already existed as first class relationship concept (I remembered briefly reading about this on the docs and extrapolated).

[sukimage]

I am learning C4 and structurizr all the way from the beginning.
Can subSystem = container "B sub-system"?

workspace {

!identifiers hierarchical

model {
    user = person "User"
    
    system = softwareSystem "System" {
        subSystem = container "A sub-system"
        subSystem -> subSystem "bootstraps itself"
    }
    
    systemB = softwareSystem "System B" {
        subSystem = container "B sub-system"
        subSystem -> subSystem "bootstraps itself"
    }

    user -> system.subSystem "Uses"
}

views {
    dynamic system {
        system.subSystem -> system.subSystem "bootstrapping step 1"
        system.subSystem -> system.subSystem "bootstrapping step 2..."           
        systemB.subSystem -> systemB.subSystem "bootstrapping step 1" 
        systemB.subSystem -> systemB.subSystem "bootstrapping step 2..."
        properties {
          plantuml.sequenceDiagram true
        }
    }
}

}