Cdk Design Patterns

Christian Bonzelet

Apr 11, 2025

Updated Apr 11, 2025

a856990

Steering Document Content

# CDK Design Patterns

# CDK Design Patterns Rules

## CDK Stacks

- Use separate stacks to model individual deployable services within a bounded context.
- Use stacks only to describe how constructs are composed and connected for various deployment scenarios.
- Create separate stacks for common resources such as networking that are shared across multiple bounded contexts.
- Keep stateful and stateless resources within a stack together to achieve high cohesion.

## CDK Constructs

### Construct Hierarchy

- Use L1 constructs only when L2 or L3 constructs are not available for a specific resource
- Use L2 constructs as the default choice for most resources
- Use L3 constructs (patterns) when implementing common architectural patterns or combine multiple resources to solve specific use cases

### Construct Structure

- Follow the standard construct initialization pattern
- Accept `scope`, `id`, and `props` parameters
- Call `super(scope, id)` in the constructor
- Initialize resources in the constructor
- Define a clear interface for construct props
- Mark required properties as non-optional
- Provide sensible defaults for optional properties
- Validate props in the constructor
- Throw clear error messages for invalid props

### Construct Naming Conventions

- Use logical IDs that describe the resource's purpose
- Avoid using generic names like "Bucket" or "Function"
- Include the resource type in the logical ID
- Use descriptive property names
- Use generated resource names instead of physical names whenever possible.

### Composition and Inheritence

- Extend existing constructs when there's an "is a" relationship
- Use extension to add default properties or behaviors to existing constructs
- Override methods only when necessary to change behavior
- Use composition when there's a "has a" relationship
- Compose constructs to create higher-level abstractions as L3 constructs
- Expose only the necessary properties and methods to consumers

### Escape Hatches

- Use escape hatches only when necessary
- Use them to access features not yet available in higher-level constructs
- Document why the escape hatch is needed
- Use `node.defaultChild` to access the underlying L1 construct
- Cast to the appropriate type using `as`
- Set properties directly on the L1 construct

## CDK Aspects

- Use CDK aspects to modify, validate, or enforce standards across all constructs within a given scope.
- Use CDK aspects to apply consistent tags across all resources
- Use CDK aspects to apply removel policies for ephemeral environments

# CDK Design Patterns # CDK Design Patterns Rules ## CDK Stacks - Use separate stacks to model individual deployable services within a bounded context. - Use stacks only to describe how constructs are composed and connected for various deployment scenarios. - Create separate stacks for common resources such as networking that are shared across multiple bounded contexts. - Keep stateful and stateless resources within a stack together to achieve high cohesion. ## CDK Constructs ### Construct Hierarchy - Use L1 constructs only when L2 or L3 constructs are not available for a specific resource - Use L2 constructs as the default choice for most resources - Use L3 constructs (patterns) when implementing common architectural patterns or combine multiple resources to solve specific use cases ### Construct Structure - Follow the standard construct initialization pattern - Accept `scope`, `id`, and `props` parameters - Call `super(scope, id)` in the constructor - Initialize resources in the constructor - Define a clear interface for construct props - Mark required properties as non-optional - Provide sensible defaults for optional properties - Validate props in the constructor - Throw clear error messages for invalid props ### Construct Naming Conventions - Use logical IDs that describe the resource's purpose - Avoid using generic names like "Bucket" or "Function" - Include the resource type in the logical ID - Use descriptive property names - Use generated resource names instead of physical names whenever possible. ### Composition and Inheritence - Extend existing constructs when there's an "is a" relationship - Use extension to add default properties or behaviors to existing constructs - Override methods only when necessary to change behavior - Use composition when there's a "has a" relationship - Compose constructs to create higher-level abstractions as L3 constructs - Expose only the necessary properties and methods to consumers ### Escape Hatches - Use escape hatches only when necessary - Use them to access features not yet available in higher-level constructs - Document why the escape hatch is needed - Use `node.defaultChild` to access the underlying L1 construct - Cast to the appropriate type using `as` - Set properties directly on the L1 construct ## CDK Aspects - Use CDK aspects to modify, validate, or enforce standards across all constructs within a given scope. - Use CDK aspects to apply consistent tags across all resources - Use CDK aspects to apply removel policies for ephemeral environments