Instances in Dynamic views

[ktali]

Dynamic views are great for throwing together quick illustrations of the more complex interactions in a model. However the selection of allowed elements within a dynamic view seems to be restricted to static structure elements. Showing the collaboration between instances would be very useful for modelling distributed systems.

Example: Peer-to-peer architecture

Take for example a P2P system. On the container level you would define an application that is at once a server and a client. The container is a single static structure element, however it is only useful if deployed in several instances to form a network. Perhaps you draw a self referential relationship for that container to illustrate that its API is called by other instances of itself.

This approach results in the core static structure diagrams becoming rather abstract. Even though they faithfully represent a "map of your code", those diagrams fail to communicate the most critical design aspects, i.e. the interrelationship of instances.

The deployment modelling features are helpful in this regard, although even these are not always sufficient. Since relationships between two StaticStructureElementInstance objects are not permitted, every relationship that you want to show in the Deployment view must be defined in the static model. This makes sense, as a deployment shouldn't magically introduce relationships between two containers for example. Here is where the self referential relationship created before comes into play: in deployment views, those automatically get transformed into relationships between individual container instances.

While this works out, the amount of relationships cluttering the static model will get unmanageable quickly. Further, it's an unviable solution for showing sequences of interactions. A deployment view represents a static environment, meant for illustrating physical placement. Dynamic diagrams should fill that gap instead. The dynamic view lacks the feature to do this out of the box though. The best you can do is show the container communicating with itself, but this is undesired.

Dynamic view semantics

This is where I get confused about the semantics of the dynamic view in C4/Structurizr. This is what is described in the book "The C4 model for visualising software architecture":

Software isn’t static though, and needs to be executed in order to actually do something useful. For this reason, it can be useful to create diagrams that illustrate what happens at runtime (a “dynamic view”) for important use cases, user stories or scenarios. To do this, I simply take the concept of sequence and collaboration/communication diagrams from UML and apply them to the static elements in the C4 model.

In UML sequence and communication diagrams, elements are instances of static structure elements. What I get now is that C4 tries to convey dynamic behavior using static structure elements as-is, hence also the constraints in Structurizr. The implication of this is probably negligible as long as you're designing software where you can skip the distinction without compromising comprehension of the diagram.

While I'd like to propose instances in dynamic views as a feature, I'm wondering whether I'm missing the philosophy or the decision to restrict dynamic views to static structure elements was misguided.

DSL used to generate examples

workspace {
    
    !identifiers hierarchical
    
    model {

        user = person "User"
        
        p2p = softwareSystem "P2P" {
            app = container "Application" {
                this -> this "Establish network with"
                this -> this "Send files to"
            }
            discovery = container "Discovery service" {
                app -> this "Get peer information from"
            }
        }
        
        user -> p2p.app "Use"
        
        twoNode = deploymentEnvironment "Two peers" {
            coordinationServer = deploymentNode "Coordination server" {
                discoveryInstance = containerInstance p2p.discovery
            }
            peerA = deploymentNode "Machine of first peer" {
                appInstance = containerInstance p2p.app
            }
            peerB = deploymentNode "Machine of second peer" {
                appInstance = containerInstance p2p.app
            }
        }

    }
    
    views {
        container p2p "Containers_All" {
            include *
            autolayout lr
        }
        
        deployment * twoNode "test" {
            include *
            autolayout lr
        }
        
        dynamic p2p "test2" {
            p2p.app -> p2p.discovery "Give me the address of peer B"
            p2p.discovery -> p2p.app "Provide address"
            // not very useful
            p2p.app -> p2p.app "Send network formation request to peer B"
            autolayout lr
        }
    }
}

[simonbrowndotje]

While I'd like to propose instances in dynamic views as a feature, I'm wondering whether I'm missing the philosophy or the decision to restrict dynamic views to static structure elements was misguided.

The philosophy behind the C4 model is that it should work sufficiently well for "most" engineering teams. Structurizr builds upon this philosophy, which is why the dynamic view support is deliberately simple - no instances, no guard conditions, no loops, no activations, no lifelines, etc.

I don't really want to add instances in dynamic views, but I am open to providing a way to build dynamic views for the deployment model though. You're actually the first to ask for this. 😀

You want something like this, correct?

[ktali]

You want something like this, correct?

Yep, well, sort of.

way to build dynamic views for the deployment model

This would be the perfect solution for the problem of showing complex interactions within a deployment, rather than showing complex interactions between instances in general. The latter is a more powerful variant.
In this regard, your answer about deliberately keeping the dynamic view simple and suitable for most systems is fair enough.

Nevertheless, having such dynamic deployment views would be very helpful. The diagram you show does solve the example scenario.