Is forward referencing of identifiers supported?

[galuszkak]

Description

Hi @simonbrowndotje ,

Thanks for the fantastic & hard work on Structurizr! I've been using it for over a year now with https://github.com/avisi-cloud/structurizr-site-generatr .

The bug that I'm experiencing is related to my idea of moving to start using !identifiers hierarchical directive.

This example DSL is failing:

workspace {

    !identifiers hierarchical

    model {
        systemTest = softwareSystem "System that we test" {
            container1 = container "Test container 1" {
                this -> systemTest.container2
            }
            container2 = container "Test container 2" {

            }
        }
    }

  views {
    container systemTest {
      include *
      autoLayout
    }

}

This would end up with error:

com.structurizr.dsl.StructurizrDslParserException: The destination element "systemTest.container2" does not exist at line 8 of /Users/galuszkak/Projects/airlift/architecture/bug.dsl: this -> systemTest.container2
        at com.structurizr.dsl.StructurizrDslParser.parse(StructurizrDslParser.java:912)
        at com.structurizr.dsl.StructurizrDslParser.parse(StructurizrDslParser.java:128)

Having semantically equivalent is working:

workspace {

    !identifiers hierarchical

    model {
        systemTest = softwareSystem "System that we test" {
            container1 = container "Test container 1" {

            }
            container2 = container "Test container 2" {
                systemTest.container1 -> this
            }
        }
    }

  views {
    container systemTest {
      include *
      autoLayout
    }

}

Steps to reproduce

With this DSL:

workspace {

    !identifiers hierarchical

    model {
        systemTest = softwareSystem "System that we test" {
            container1 = container "Test container 1" {
                this -> systemTest.container2
            }
            container2 = container "Test container 2" {

            }
        }
    }

  views {
    container systemTest {
      include *
      autoLayout
    }

}

It will fail with error:

com.structurizr.dsl.StructurizrDslParserException: The destination element "systemTest.container2" does not exist at line 8 of /Users/galuszkak/Projects/airlift/architecture/bug.dsl: this -> systemTest.container2
        at com.structurizr.dsl.StructurizrDslParser.parse(StructurizrDslParser.java:912)
        at com.structurizr.dsl.StructurizrDslParser.parse(StructurizrDslParser.java:128)

Screenshot

No response

Code sample

No response

Configuration

No response

Severity

Major

Priority

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

More information

While I can't confirm, I will try to see if our company has the budget to fix this bug. Would you be able to provide any potential estimation and rate for fixing this bug?

[simonbrowndotje]

This is as expected ... the DSL is like a programming language, and you can't forward reference elements that haven't yet been created.

[galuszkak]

Thanks for such a quick response @simonbrowndotje. Maybe I thought about it a little differently and thought about the DSL as a better way to define data structure. In a nutshell, I thought about it more like i.e. OpenAPI, you can reference an element that wasn't yet created in the same file. I thought it was a similar experience here ;). My initial thinking is that DSL is much more declarative than imperative. A good example from the OpenAPI is in the documentation where ContactInfo is referenced in the User object even if ContactInfo wasn't in the scope yet.
https://swagger.io/docs/specification/data-models/data-types/#object

components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: integer
        name:
          type: string
        contact_info:
          $ref: '#/components/schemas/ContactInfo'
    ContactInfo:
      type: object
      properties:
        email:
          type: string
          format: email
        phone:
          type: string

My thinking was that you first create the model in Java SDK by:

• First, create all elements (software systems, containers, components, etc.).
• As a second step, it goes through all relationships gathered when parsing elements on some stack and evaluates them to create them in the model.

This would be much nicer because if you have outbound relationships between containers, you would like to define them in that container.

I'm not sure if that makes sense, but I thought about it that way.

[simonbrowndotje]

My thinking was that you first create the model in Java SDK by:

Scripts, plugins, and the implied relationships processing make a two-pass parser non-trivial, so I have no plans to change this behaviour I'm afraid.

[simonbrowndotje]

This would be much nicer because if you have outbound relationships between containers, you would like to define them in that container.

You might want to look at LikeC4, which does support this feature -> https://likec4.dev/docs/dsl/references/#hoisting

[galuszkak]

Hi @simonbrowndotje ,

Following up on this. What is your recommendation when there are multiple teams owning part of the workspace?

In our case teams are owning Containers (as a deployable units). Therefore our structure is more or less like this:

workspace {

    !identifiers hierarchical

    model {
        customer = person "Customer"
        customerSupport = person "Customer Support"
        ooms = softwareSystem "Offer & Order Management System" {
            pipelineService = container "Pipeline Service" "Handles operations related to data pipelines." "Java, Spring Boot" {
                !docs "../application/pipelineservice/docs/"
                !include "../application/pipelineservice/main.dsl"
                tags "Pipelines"
            }
            restApi = container "REST API" "Handle REST API Calls" "Java, Spring Boot" {
                !docs "../application/rest-api/docs/"
                !include "../application/rest-api/main.dsl"
                tags "APIs"
            }

With that teams can own architecture of components and relationships to other containers from their own codebase. Is there a smart way to do it if you have multiple teams involved in maintaining the architecture of different containers that are owned by team without centralizing this into one file?