Code Organization recommendation
_This message was extracted from a discussion that originally took place in Gruntwork Community Slack. Names and URLs have been removed where appropriate_ **From a customer** This is kind of an abstract, strategy question but here goes. With our refarch, we have a number of DRY violations (in particular, `ecs-deploy-runner` s in each account). Is it generally advisable to identify these things, then introduce a higher-level module (i.e. by wrapping the Gruntwork one) with all the commonality to reduce the size of the leaf `terragrunt.hcl` files? So with the `ecs-deploy-runner` example, you might end up with a `my-ecs-deploy-runner` module which wraps it and then the `terragrunt.hcl` file in each account is just the vars that are different (e.g. the vpc id)
**From a grunt** Hello! So I did ask internally, and think you’re actually on the right path here! So, if you were to abstract away the `ecs-deploy-runner` and put the common things between them in one place, so you only have to update them once, that is a good step forward. The challenge might come as you update the `ecs-deploy-runners`, in case there’s some unnoticed bugs by the refactoring itself. Something interesting to share - `terragrunt` is actually being updated so that we could re-architecture the `infrastructure-live` repo very soon, and it will be easier to avoid duplication like you’re having. Have a read here [https://github.com/gruntwork-io/terragrunt/issues/1566](https://github.com/gruntwork-io/terragrunt/issues/1566) :slightly_smiling_face: