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 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.

So, there is no built in way to actually get a container or component level view that is consistently on the same abstraction layer/level throughout. (This is probably the biggest gotcha for me so far)

So, I tried the workaround provided here at the end of the page here:
https://docs.structurizr.com/dsl/cookbook/container-view-multiple-software-systems/

The first workaround, expressing the relationship both in the model and in the view, works (ex1):

!identifiers hierarchical 
model {
    [...]
    s1.c1 -> s1.c2  // express relationship once...
}
views {
    container s1 {
        include s1.c1 s1.c2  // then express relationship again. I don't really like it.
    }
}

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

So I try the 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.

This is an example where I added a third system to the simple model and the view includes everything, it seems. (full example 3 below) Plantuml render:

---

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 -> s1.c2
    }

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

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 -> s1.c2
    }

    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 -> s1.c2
    }

    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.)