Enterprise Deployment Guide

Module Composition Strategies

Structure modules in layered architecture patterns to balance reuse, specificity, and correct build order.

Edit this page on GitHub

Module Composition Strategies

As adoption scales, organizations should structure their modules to balance reuse and specificity.

Layered Architecture

  1. Base Infrastructure (Foundation): Modules that ingest raw cloud accounts, VPCs, and physical datacenters.
  2. Domain Modules (Platform): Modules that add platform services like Kubernetes clusters, centralized logging gateways, and Identity providers.
  3. Security Baselines (Compliance): Governance modules that automatically attach controls (e.g., rescile-ccm-lite) across all other layers.
  4. Project Modules (Workloads): Specific applications and their databases, relying on the foundation.

Composition via module.toml

A top-level “Enterprise Blueprint” module can import all these layers as dependencies, ensuring they are evaluated in the correct order.

Use resource aliasing if different domain modules have overlapping terminology to prevent auto-linking collisions. Layered design guarantees that foundational resources are built first, allowing workload models to reliably attach to them.

Overlay Patterns

Teams can use the --module-params CLI argument or inject local data/ files to override or parameterize standard enterprise modules for their specific environment.