You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow up of structurizr/dsl#67: deploymentGroups are great but they have a limitation that makes them hard to use sometimes: Once in a group, instances "lose" connections with objects outside of the group.
In the example bellow, we can see that the DB container is getting isolated as soon as deploymentGroups are used. I could add it to the group too, but for complex diagrams, it becomes really hard to maintain these groups.
workspace "deploymentGroup" {
model {
ss = softwaresystem "Application" {
rails = container "Rails" "Fullstack service" "Ruby on Rails"
sidekiq = container "Sidekiq" "Jobs queue" "Ruby on Rails"
redis = container "Redis" "State" "redis server"
db = container "DB" "Database" "PostgreSQL"
}
rails -> redis "Cache and queue jobs" "Redis protocol"
sidekiq -> redis "Fetch and execute jobs" "Redis protocol"
rails -> db "Store and retrieve metadata" "PostgreSQL protocol"
sidekiq -> db "Store and retrieve metadata" "PostgreSQL protocol"
live = deploymentEnvironment "Live" {
redis_cache = deploymentGroup "Redis Cache"
redis_persistent = deploymentGroup "Redis Persistent"
deploymentNode "Application" {
containerInstance rails redis_cache,redis_persistent
}
deploymentNode "Sidekiq" {
containerInstance sidekiq redis_persistent
}
deploymentNode "Redis Cache" {
containerInstance redis redis_cache
}
deploymentNode "Redis Persistent" {
containerInstance redis redis_persistent
}
deploymentNode "DB" {
containerInstance db
}
}
}
views {
deployment ss "Live" "AppDeployment" {
include *
autolayout lr
}
}
}
I wonder if it wouldn't be best to not force the external connections to a group to declare they're part of the group (ex: containerInstance rails redis_cache,redis_persistent) and instead let the user define or redefine the new connections.
In the example above again, the "Cache and queue jobs" relationship works fine when a single node hosts redis. But in this case, we have two nodes using the same component, with two different purposes. I'd like to be able to define that rails is using redis for cache in the redis_cache group only.
Priority
Low
Resolution
I have no budget and there's no rush, please add this feature for free
More information
No response
The text was updated successfully, but these errors were encountered:
Description
Follow up of structurizr/dsl#67:
deploymentGroups
are great but they have a limitation that makes them hard to use sometimes: Once in a group, instances "lose" connections with objects outside of the group.In the example bellow, we can see that the
DB
container is getting isolated as soon asdeploymentGroups
are used. I could add it to the group too, but for complex diagrams, it becomes really hard to maintain these groups.I wonder if it wouldn't be best to not force the external connections to a group to declare they're part of the group (ex:
containerInstance rails redis_cache,redis_persistent
) and instead let the user define or redefine the new connections.In the example above again, the
"Cache and queue jobs"
relationship works fine when a single node hosts redis. But in this case, we have two nodes using the same component, with two different purposes. I'd like to be able to define thatrails
is using redis for cache in theredis_cache
group only.Priority
Low
Resolution
I have no budget and there's no rush, please add this feature for free
More information
No response
The text was updated successfully, but these errors were encountered: