Workspaces to extend multiple workspaces

[johncyril]

Firstly, thank you @simonbrowndotje for Structurizr. After your NDC Oslo talk, I've been trying to model what I suppose we can call an "Enterprise System"

We have several domains which we wish to manage in separate workspace files for maintainability and to easily split responsibilities between teams.
That said, we'd love to be able to model relationships between the subsystems we have across domains and build a full picture of our software estate, with full zoom in and zoom out capabilities between and within our domains.

Having attempted both the !includes and workspace extension techniques, we've found some drawbacks to each of these.

For a moment, we thought the BigBank PLC example was doing what we were after, but soon realised the root workspace.dsl was a manual merge of multiple workspaces 😂

We've also looked at the system-catalog example which comes pictorially close to what we're trying to achieve, which I think is also broadly the same as #238

We've been structuring workspaces as follows

• domainA
  -- workspace.dsl
• domainB
  -- workspace.dsl
• domainC
  -- workspace.dsl
• workspace.dsl (full system workspace which we'd like to be the aggregator)

We'd like each of these workspaces to be independently "compliable", such that when we target with STRUCTURIZR_WORKSPACE_PATH=DomainA this can work in structurizr lite and be also viewed as a discrete workspace in structurizr on prem
The extensions approach where we would have a !ref on a softwareSystem in the DomainA.workspace.dsl that is actually defined in the root workspace.dsl, sadly doesn't work for our use case when we look to compile DomainA.workspace.dsl in isolation.

With the !includes syntax, this seems to only support DSL fragments as per the docs (and trial/error 😀) which given the above also doesn't work for our use case.

It's not clear how the system-catalog approach would fare for what we're trying to achieve. The syntax for the domain workspaces seems to suggest that they wouldn't be independently compliable?

What has yielded some promise though, is using workspace extensions but inverting the dependency to essentially pull up the definitions from a domain's DSL into the root workspace.dsl. This does allow us to have a distinctly compliable domain workspace, which can then be referenced by the parent/root.

The obvious drawback is that only one workspace can be referenced.
If the DSL allowed for us to extend multiple workspaces (or maybe another keyword would be more appropriate) we could have something like this:

workspace extends domainA/workspace.dsl
workspace extends domainB/workspace.dsl
workspace extends domainC/workspace.dsl {
   
   !ref domainA.softwareDomain1
   !ref domainB.softwareDomain1

domainB.softwareDomain1 -> domainA.softwareDomain1 "invokes"

}

This way:

• Domain workspaces can be independently compiled and worked on by different teams
• An aggregating workspace can be used to model the relationships between those domains and possibly introduce other elements in its definition.

What are your thoughts on something like this?

[simonbrowndotje]

Hard to answer your question without some example DSL files, but I'd probably just do something like this:

- workspace.dsl (!includes domainA/model.dsl, domainB/model.dsl, domainC/model.dsl)
- domainA
  - model.dsl (model)
  - workspace.dsl (separately usable workspace, !includes model.dsl)
- etc

[johncyril]

Thanks so much -- That's solved our use case perfectly 🙏