Mixing DeploymentGroup instances and non-DeploymentGroup ones

[pjjv]

When working with deploymentGroups, it only generate links within deployment group, but not with non-deploymentGroup constrained containers:

 workspace {
 
    model {
        user = person "User"
        softwareSystem = softwareSystem "Software System" {
            webapp = container "Web Application"
            bus = container "Message Bus"
            app = container "App"
            db = container "DB"
            webapp -> app
            app -> db
            app -> bus
        }
        ext = softwareSystem "ERP" {
            -> bus
        }

        user -> webapp "Updates details"

        deploymentEnvironment Prod {
            DC1 = deploymentGroup DC1
            DC2 = deploymentGroup DC2
            
            deploymentNode FE "" "" "" 9 {
                containerinstance webapp
            }
            
            deploymentNode EUApp {
                deploymentNode App "" "" "" 6 {
                    containerinstance app DC1
                }
                DB1 = deploymentNode DB "" "" "MASTER-SLAVE" 2 {
                    containerinstance db DC1
                }
                
                deploymentNode Comm "" "" "" 2 {
                    containerinstance app DC2
                    containerinstance bus DC2
                }
                
                // DB2 name needed as 'this' does not work in deployment nodes
                DB2 = deploymentNode DBreplica {
                    containerinstance db DC2
                    -> DB1 "Sync"
                    DB1 -> DB2 "Copy Master data"
                }
            }
        }
    }

    views {
        theme default
        deployment * Prod {
            include *
        }
    }
}

Rendered it looks like no link between webapp and app:

Is there a way to change behaviour between deploymentGroup-constrained and non-constrained instances:

From	To	Result
non-constrained	non-constrained	generate always
non-constrained	constrained	generate always
constrained	non-constrained	generate always
constrained	constrained	generate only within same group

Or is there another way?

[simonbrowndotje]

What you're seeing is by design. What's your goal here, and what happens if you don't use deployment groups at all?

[pjjv]

Originally, I tried to use it for modeling deployments with optional container/components in 2 centres, with shared FE (in example is simplified version) and some shared services (not shown in example) and optional compliance-related containers.

1. I tried with deployment groups and I found the "missing" flows between shared components

2. I tried to "help" deployment group with additional flows between FE and shared services' deployment nodes, but then I went into issue with maintainability (e.g. you have to properly decide how to group deployment nodes to use identifiers) in the deployment environment, sometimes you need to make "shared deployment node" spanning both data centres only to have propagated identifiers, which does not look good at views anyway

3. Tried to use tags, but the filtering in views is even harder

• you have to design specific tag system and use them on each container/SW system flows
• it leads to hierarchy of filtered views and even some cases cannot be easily expressed in expressions like "filter out all relations between DC1 and DC2 elements"
• BTW sw architecture and views solving issue in deployment

4. Used location-aware containers (e.g. orderProcessingEU, orderProcessingUS), which looks good until you add components and have to maintain consistency

• again it seems to me solving deployment case in software architecture
• if you have dynamic views, people keep asking for all versions (i.e. orderProcessingEU and orderProcessingUS)

5. Used 2 deployment environments for modelling each data center separately with "data center deployment for the other node"

• then you miss the shared services, as they split to two different views
• for majority views it was good, but not for availability, DevOps and migration discussions

6. Returned back to solution ad 1) and tried other options:
   6.1) multiple deployment groups on container instance does not work
   6.2) deployment group extensions proposal (i.e. DC group is composed of DC1 and DC2) is another option, but you currently extend only workplaces and yet not other stuff. Also I found in majority of SW systems we have, unconstrained <-> constrained case is enough (only 1 system will need some solution like 2), but it is maintainable)
   6.3) submitted this proposal as it changed only unconstrained <-> constrained behaviour before you design more general solution like 6.2)

• as I feel it is deployment model decision, it should lay there and neither complicate SW architecture or views/tag system
• in my opinion: unconstrained case is (in current design) treated as separate deploymentGroup and there is no clean way to express communication between shared and group constrained currently in deployment part of the model

In small model (like the demo I sent) you can use the case 4) easily, but my has tens of containers and lots of infrastructure nodes for HSM, load balancers etc required in both data centres

What solution do you propose to use?

[simonbrowndotje]

Regarding your example, is this what you're looking for?

[pjjv]

Yes, that's it.

[simonbrowndotje]

I've added a way to specify multiple deployment groups for software system/container instances, which you can try out via a dev version of Structurizr Lite (structurizr/lite:dev):

 workspace {
 
    model {
        user = person "User"
        softwareSystem = softwareSystem "Software System" {
            webapp = container "Web Application"
            bus = container "Message Bus"
            app = container "App"
            db = container "DB"
            webapp -> app
            app -> db
            app -> bus
        }
        ext = softwareSystem "ERP" {
            -> bus
        }

        user -> webapp "Updates details"

        deploymentEnvironment Prod {
            DC1 = deploymentGroup DC1
            DC2 = deploymentGroup DC2
            shared = deploymentGroup Shared
            
            deploymentNode FE "" "" "" 9 {
                containerinstance webapp shared
            }
            
            deploymentNode EUApp {
                deploymentNode App "" "" "" 6 {
                    containerinstance app DC1,shared
                }
                DB1 = deploymentNode DB "" "" "MASTER-SLAVE" 2 {
                    containerinstance db DC1
                }
                
                deploymentNode Comm "" "" "" 2 {
                    containerinstance app DC2,shared
                    containerinstance bus DC2
                }
                
                // DB2 name needed as 'this' does not work in deployment nodes
                DB2 = deploymentNode DBreplica {
                    containerinstance db DC2
                    -> DB1 "Sync"
                    DB1 -> DB2 "Copy Master data"
                }
            }
        }
    }

    views {
        theme default
        deployment * Prod {
            include *
        }
    }
}

[pjjv]

Thank you, the development release works for me.

Used the real life workspace.

[simonbrowndotje]

This change is now available via the Structurizr CLI/Lite/cloud service/on-premises installation.