Add more advanced features for groups about dsl HOT 12 CLOSED

It's a similar reason to why I've resisted creating view-specific styling (i.e. styles that are only used on a single view) ... I want the views to show a consistent representation of the model. Creating an alternative version of the model, with different groupings, can be done using the workspace extensions feature though, for example:

• Base workspace with no groups
• Domain groups
• Layer groups

from dsl.

You're correct, the groups feature is just a way to group elements at the same level on a diagram. Removing these limitations essentially requires redeveloping the entire way that Structurizr works ... i.e. moving away from having a predefined set of abstractions (software systems, containers, and components) to an arbitrary set of hierarchical abstractions, with zooming and implied relationships at all levels. To set expectations, it's very unlikely this will happen I'm afraid.

from dsl.

I'm not sure I understand what you're asking in that case. Let's look at this piece by piece.

I could create groups representing domains in a way I would see the systems grouped based on domains, so that would be easier to understand.

This seems possible with the current functionality - what's missing for you here?

workspace {

    model {
        1 = group "Domain 1" {
            a = softwareSystem "A"
            b = softwareSystem "B"
        }
        2 = group "Domain 2" {
            c = softwareSystem "C"
            d = softwareSystem "D"
        }
        
        a -> b
        b -> c
        c -> d
    }

    views {
        systemLandscape {
            include 1 2
            autoLayout lr
        }
    }
    
}

from dsl.

If you want to use nested groups you need to add in the model area addtional property

properties {
"structurizr.groupSeparator" "/"
}

List of properties available here
https://structurizr.com/help/properties

from dsl.

Thanks Simon for quick response. I undertand your concerns, but before rejecting let me clarify something: I'm not suggeting different levels of abstractions, I do want to keep using the level of abstractions defined in C4 model. I'm suggesting these new features for groups just to have a way to group elements in the view based on some criteria. The views I described (Layers, Domains, Ownership) are just the result we could get by using groups in the predefined set of abstractions. For example, let's say I have a System Context Diagram with big number of systems. I could create groups representing domains in a way I would see the systems grouped based on domains, so that would be easier to understand. Alternatively, or even additionally (as described in my request), I could decide on creating groups representing layers in a way I would see the systems grouped based on layers, so that would be easier to understand. The same example could be valid for a Container Diagram.
In fact, I can partically achieve that nowadays by creating groups, but with the limitations described.

from dsl.

Makes sense, let's go step by step. So, starting from your example, let's say that, in addiction to the landscape view grouping by domains, I want to create an separate landscape view grouping by layers. Then, for example, I would like to be able to create 2 new groups: Layer 1 and Layer 2 adding A+C and B+D, respectively. Then, the additional Landscape view would show:

So, for now, it is refering to some of my points:

• An element cannot be part of more than one group.
• They are automatially displayed. There is no option to decide if we want to group or not elements in a view. Or even select the specific grouping we want to see.

Let me know what you think about it. I can continue with the rest of the points after that. Thanks

from dsl.

Interesting! Honestly, I was not aware of that feature. Thanks for sharing. I'll explore it.
Let me then come to the next step

Let's assume I can achieve my goals using the workspace extension feature. Then, on the new workspaces for Domains and Layers I would need to add the elements to the specific groups. In the example you shared, they are selected one by one. It would be great if I can add elements in a group based on tags. So, in the original workspace I can use the tags like "domain_1", "domain_2", "layer_1", "layer_2", and the views in the extended workspaces would automatically group elements accordantly. What do you think?

This is related to my point:

• When defining a group, we need to explicitelly list the elements in the group. We cannot create a group based on tags.

from dsl.

Including elements by tag is very useful for views, where you only want to show a subset of the model. Having different groups is really about manipulating the model though ... and once you get to that stage, it's possibly time to break out of the DSL and into code. For example, with the Java client library and DSL parser as dependencies, you can do something like this:

public static void main(String[] args) throws Exception {
    StructurizrDslParser parser = new StructurizrDslParser();
    parser.parse(new File("base-workspace.dsl"));
    parser.getWorkspace().getModel().getSoftwareSystems().stream().filter(ss -> ss.hasTag("Layer 1")).forEach(ss -> ss.setGroup("Layer 1"));

    // ...
}

from dsl.

Sorry for the delay in my response. I see, thanks for sharing.

I've been rethinking about this topic and wanted to share my thoughts: I have the feeling we can see groups from two different perspectives (probably two separate concepts).

On one hand, I fully agree with you on having groups as part of the model: for example, grouping systems in ecosystems, grouping containers in subsystems, grouping components in modules. I do have some usecases of groups in that sense, and some part of my initial request (for supporting relatioships and nested groups) are related to this concept of group. In this case, I also agree with you that doesn't make sense to implement a way to add elements to a group based on tags.

On the other hand, there are some other usecases in which I see "grouping" (maybe we should use a different name) as a view feature, not part of the model, in which I'm basically interested on keeping elements together according to some criteria. In parctice, it would be like disabling autolayout and reorganizing the elements to manually group all of them according to that spefific criteria. From my view, this feature would help a lot and would provide lot of flexibility. In this case, as a "grouping" feature on views, creating "groups" based on tags makes more sense.

You already shared some concerns related, but I would appreciate your feedback on this high level proposal

from dsl.

It's a similar reason to why I've resisted creating view-specific styling (i.e. styles that are only used on a single view) ... I want the views to show a consistent representation of the model. Creating an alternative version of the model, with different groupings, can be done using the workspace extensions feature though, for example:

• Base workspace with no groups
• Domain groups
• Layer groups

I wanted to view the examples for the Domain Groups and Layer Group do not work anymore.
Both yield and error:

The element is already registered with an identifier of "a" at line 5: softwareSystem "A"
@simonbrowndotje Could you provide new versions?

from dsl.

It doesn't look like this works any more ... feel free to raise a new issue.

from dsl.

Since the discussion on extending features for groups is still open, I'd like to ask, if you consider to add the capability to set the background color of the box of the group or other stylings.
We are looking into using groups for different domains (as in the example in the comments above) - some simple coloring would be very handy and improve the readability of the diagram.
What do you think @simonbrowndotje ?

from dsl.