DSL, CLI: A container/component view includes all elements, filter approach does not work as-is

[mawid6]

Description

(the title is not the greatest, sorry)
I have realized that all views are in a way "good old context views" - in the sense that:
All relationships outside of the element that is in focus (zoomed in) are illustrated at the softwaresystem level.
This seems to apply for all level views - container, component..
It also applies regardless of the level at which the relationships were expressed.

As-is

If I have: two systems s1 & s2, they have several containers, c1 to c4 - and there is a relation s1.c1 -> s2.c1. The default container view (I mean container s1 include * ) renders a diagram with a relation from s1.c1 to s2, not to s2.c1.

This is described on the page I link to below:

"By default, the include * statement, when used inside a container view definition, will include all of the containers inside the software system in scope, along with any external software system dependencies."

There is an example image on the page but I am choosing to provide another one where the model has more elements, which is needed to illustrate the issue further on:

Expected

What I would want, as well, is something like this:

What to do? Well, if one wants to display the relationship using elements from the same abstraction layer/level, e g container to container or component to component - two approaches are suggested on this page:

https://docs.structurizr.com/dsl/cookbook/container-view-multiple-software-systems/

1. The first approach basically means to express the relationship both in the model and in the view (ex1) as a filter in an include statement:

!identifiers hierarchical 
model {
    [...]
    s1.c1 -> s2.c1  // express relationship once...
}
views {
    container s1 {
        include s1.c1 s2.c1  // then express relationship again. I would like to avoid this.
    }
}

This does display the relationship, but first, it does not display the rest of s1 containers, the filter is "absolute".

Since I am after a view showing all the containers of a system (e g s1) and their relationships to other containers, as in the above diagram under "expected". So this is not actually what I am after.

Secondly, I would ideally like to avoid having to repeat the model in the views. As far as possible.

2. So I try the second approach, an example further down on the page - but the issue is that I cant get it to work, since this will include all elements with the parent (example 2):

views {
    container s1 {
        include element.type==container
        include element.parent==s1 element.parent==s2
    }
}

So, I get all containers of system 2, not just the ones that are dependencies to the elements that are in focus for the view (system s1).

Here is the plantuml render, but the problem is not with the rendering and appears regardless of chosen render:

Full example 2 below.

I also found that: All systems will have its containers in this view. Not just the system in focus (s1 in example) and any dependencies (s2 in example), but any s3, s4, etc. So the approach seems to miss something. It seems that only the filters are used and the statement indicating what system/container is in focus (container s1) does not translate to any filtering, in this approach.

---

Full example 1:

workspace {
    !identifiers hierarchical 

    model {
        s1 = softwareSystem "Software System 1" {
            c1 = container "Container 1"
            c2 = container "Container 2"
        }

        s2 = softwareSystem "Software System 2" {
            c1 = container "System 2 Container 1"
            c2 = container "System 2 Container 2"
        }
        
        s1.c1 -> s2.c1
    }

    views {
        container s1 {
            include s1.c1 s2.c1
        }
    }
}

Full example 2:

workspace {
    !identifiers hierarchical 

    model {
        s1 = softwareSystem "Software System 1" {
            c1 = container "Container 1"
            c2 = container "Container 2"
            c3 = container "Container 3"
            c4 = container "Container 4"
        }

        s2 = softwareSystem "Software System 2" {
            c1 = container "System 2 Container 1"
            c2 = container "System 2 Container 2"
            c3 = container "System 2 Container 3"
            c4 = container "System 2 Container 4"
        }
        
        s1.c1 -> s2.c1
    }

    views {
        container s1 {
            include element.type==container
            include element.parent==s1 element.parent==s2
        }
    }

}

Full example 3:

workspace {
    !identifiers hierarchical 

    model {
        s1 = softwareSystem "Software System 1" {
            c1 = container "Container 1"
            c2 = container "Container 2"
            c3 = container "Container 3"
            c4 = container "Container 4"
        }

        s2 = softwareSystem "Software System 2" {
            c1 = container "System 2 Container 1"
            c2 = container "System 2 Container 2"
            c3 = container "System 2 Container 3"
            c4 = container "System 2 Container 4"
        }

        s3 = softwareSystem "Software System 3" {
            c1 = container "System 3 Container 1"
            c2 = container "System 3 Container 2"
            c3 = container "System 3 Container 3"
            c4 = container "System 3 Container 4"
        }

        
        s1.c1 -> s2.c1
    }

    views {
        container s1 {
            include element.type==container
            include element.parent==s1 element.parent==s2
        }
    }

}

Steps to reproduce

1. Go to structurizr.com/dsl
2. Paste examples provided
3. Click render

Screenshot

No response

Code sample

No response

Configuration

I used online https://structurizr.com/dsl to reproduce with generic example code.

Severity

Major

Priority

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

More information

I find this rather limiting, and a surprise to me. Ideally, there would be a way to say that I want a component or container level view, where all constituent elements are on the chosen view level. But maybe this is a philosophical / approach question?

I understand that you certainly would find a view e g focusing on one system (s1) containers and wanting to abstract away / not view the detailed level of the dependencies, but in many cases this does not make alot of sense: A reader would have to click around to two different diagrams to get a consistent view of what is going on at a certain abstraction level/layer for one single interaction/depedency.

Thinking about it further, maybe the dynamic view construct that you have would be a solution to that, in a way. I have not yet explored those! But I still feel that a static view that is consistently on the indicated abstraction layer would be very useful, and is a very common part of my approach / philosophy to explaining, reading and understanding things.

(Thanks again for your work. I really hope I can make our little poc gain traction here.)

[simonbrowndotje]

I'm not sure I understand what you're trying to do here. Take example 3, just include * will work as you don't have any relationships outside of the software system in scope ... s1.c1 and s1.c2 are inside the same software system.

workspace {
    !identifiers hierarchical 

    model {
        s1 = softwareSystem "Software System 1" {
            c1 = container "Container 1"
            c2 = container "Container 2"
            c3 = container "Container 3"
            c4 = container "Container 4"
        }

        s2 = softwareSystem "Software System 2" {
            c1 = container "System 2 Container 1"
            c2 = container "System 2 Container 2"
            c3 = container "System 2 Container 3"
            c4 = container "System 2 Container 4"
        }

        s3 = softwareSystem "Software System 3" {
            c1 = container "System 3 Container 1"
            c2 = container "System 3 Container 2"
            c3 = container "System 3 Container 3"
            c4 = container "System 3 Container 4"
        }

        
        s1.c1 -> s1.c2
    }

    views {
        container s1 {
            include *
            autolayout
        }
    }

}

[mawid6]

I apologize, so many goofs in that post. What I am after is an illustration of a container relationship s1.c1 -> s2.c1 - which I totally missed and messed up.
So, I have revised the post, fixed the goofs (hopefully), and clarified. I hope it makes better sense now.

Thanks for reading my ramblings.

[simonbrowndotje]

Thanks for the clarifications. Here's a modified example 3:

workspace {
    !identifiers hierarchical 

    model {
        s1 = softwareSystem "Software System 1" {
            c1 = container "Container 1"
            c2 = container "Container 2"
            c3 = container "Container 3"
            c4 = container "Container 4"
        }

        s2 = softwareSystem "Software System 2" {
            c1 = container "System 2 Container 1"
            c2 = container "System 2 Container 2"
            c3 = container "System 2 Container 3"
            c4 = container "System 2 Container 4"
        }

        s3 = softwareSystem "Software System 3" {
            c1 = container "System 3 Container 1"
            c2 = container "System 3 Container 2"
            c3 = container "System 3 Container 3"
            c4 = container "System 3 Container 4"
        }

        s1.c1 -> s2.c1
    }

    views {
        container s1 {
            include "->element.parent==s1-> && element.type==container"
            autolayout
        }
    }

}

If you need something more than the include expressions provide, you can always jump out to a script or plugin.

[mawid6]

Thanks again Simon. That does work for this case.

One would think that understanding the default configurations of the views might stick, but somehow I get confused. Atleast I am old enough that I can recognize when simple things elude me simply because they go against my worldview. :-)

I created a small cheat sheet for others here to understand what you say in the c4model start page, i e https://c4model.com/#ContainerDiagram and component. I will work with the idea above and see how it pans out.

[quentinproust]

Thanks for the question & answer 😃

I struggled to find the right notation, I was putting the arrow -> on the wrong place. Perhaps a few typical examples on this section would help people get this right more easily https://docs.structurizr.com/dsl/expressions#element-expressions