Domain-Driven Infrastructure: Organize Your Terraform by Reason to Change
Exploring the flaws of traditional technology-based Terraform structures and the solution through Domain-Driven Infrastructure.
Stock photo for illustration only, not from the actual event
- Traditional technology-based Terraform directory structures cause code sprawl when business needs change.
- Domain-Driven Infrastructure applies the principle of organizing by reason to change to cloud infrastructure.
- The real boundary in Terraform is the State or terraform apply unit, not just moving directory folders.
- Tools like Terragrunt or Terramate handle execution mechanisms, while this discipline guides boundary decisions.
One morning, a new engineer on the team asked a simple question regarding whether the Lambda function for a new notification feature should reside inside the modules/ directory or somewhere else. Given that the existing structure already featured a modules/lambda/ directory, placing it there seemed like the obvious choice before hesitation intervened. The notification feature belonged to the order workflow, hiding two distinct questions inside a single query about placement, which the directory structure failed to differentiate.
The conversation concluded in the familiar way typical of such discussions, resulting in the decision to place it inside modules/lambda/ temporarily for convenience.
Most professionals are likely familiar with traditional Terraform repository structures featuring a layout like:
- A modules/ folder containing vpc/, ecs/, rds/, iam/, and lambda/
- An environments/ folder containing dev/ and prod/
This layout functions adequately, executing plans and applies in an organized manner until business requirements shift. Whether shipping a new feature, scaling up due to doubled traffic, or revising permissions due to compliance changes, each business request demands a single change yet forces developers to navigate across vpc/, ecs/, rds/, iam/, secrets/, and cloudwatch/ directories.
Back when development followed this workflow, code review sessions rarely proceeded as expected. Verifying correctness was straightforward, but determining safety before application proved extremely difficult, requiring teams to consult whoever remembered which external components depended on the modified security group.
"Software design has a word for this: low cohesion. Things that change together are stored apart."
Software design possesses established vocabulary built over decades of work concerning cohesion, coupling, and separation of concerns, maintaining items that change together in unified locations. Somehow, this essential vocabulary failed to influence infrastructure repositories.
Stock photo for illustration only, not from the actual event
From an architectural perspective, Domain-Driven Infrastructure acts as a bridge uniting software application design principles with infrastructure engineering. Shifting perspective away from mere technical categorization toward identifying resources bound by shared operational catalysts significantly reduces impact assessment complexity and restricts blast radiuses.
The author defines this approach as Domain-Driven Infrastructure, representing the discipline of declaring domain boundaries across both code and execution. A domain constitutes a unit sharing a reason to change, a specific owner, a regulatory scope, and a risk boundary. Within Terraform, the execution boundary corresponds directly to the state.
In summary: organize according to the reason to change rather than technology categorization.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment