A Domain-Driven Cloud Primer

Domain-Driven Cloud (DDC) is an approach for creating your organization’s cloud architecture based on the bounded contexts of your business model. DDC extends the principles of Domain-Driven Design (DDD) beyond traditional software systems to create a unifying architecture approach across business domains, software systems and cloud infrastructure.

Overview

Domain-Driven Cloud Explained

Domain-Driven Cloud:

  • Extends the principles of DDD beyond traditional software systems to create a unifying architecture spanning business domains, software systems *and* cloud infrastructure (BizDevOps).

  • Creates a cloud architecture that evolves as your business changes, improves team autonomy and promotes low coupling between distributed workloads.

  • Simplifies security, governance and cost management in a way that promotes transparency within your organization.

  • Promotes team autonomy by giving teams the ability to innovate within guardrails.

Domain Driven Discovery Loop

Expand image

Benefits of Domain-Driven Cloud

Aligning your cloud architecture to your organization’s business model has benefits including:

  • Evolves with your Business
  • ImprovesTeam Autonomy
  • Promotes High Cohesion and Low Coupled Architecture
  • Increases Cost Transparency
  • Domain-Aligned Security
  • Repeatable with Code Templates

Many organizations base their cloud architecture on their org structure. We think this is a mistake and that DDC is a better alternative for one simple reason: your business model is more stable than your org structure!

DDC is aligned to AWS and Azure’s well-architected frameworks, so you can use DDC and follow their best practices, too.

Cloud architecture is aligned to more stable bounded contexts
Expand image

Implementing

Want to implement Domain-Driven Cloud in your organization? Here’s the basic recipe with real-life examples from one of our customers, a medical supply company, who migrated to Azure.

1
Step one

Start with Bounded Contexts

Problem we are solving, people that are impacted, outcomes we aim to achieve, constraints on the solution.
Expand image

Identify Bounded Contexts

Start with identifying the bounded contexts for your business model, as described in Domain-Driven Discovery. Organize your bounded contexts into two groups:

  • Domain contexts are directly aligned to your business model.
  • Technical contexts support all domain contexts with shared infrastructure and services.
2
Step two

Build a Solid Foundation

Organize Into Layers

Organize your cloud architecture into three layers: Application, Platform and Foundation. Align your bounded contexts to these layers. Not sure what services should run in each layer? No problem, our Cloud Capabilities Checklist can help.

Problem we are solving, people that are impacted, outcomes we aim to achieve, constraints on the solution.
Expand image
Bounded contexts with message flows diagram
Expand image

Create Azure Management Groups

If using Azure, create Management Groups (MG’s) for each bounded context. Name the MG the same as the bounded contexts.

Cloud Architecture Layers
Expand image

Create AWS Organizational Units

If using AWS, create Organizational Units (OU’s) for each bounded context. Name the OU the same as the bounded contexts.

Decide on your Taxonomy

Decide on your AWS Account or Azure Subscription taxonomy. DDC recommends starting with one OU/MG and at least two Accounts/Subscriptions per bounded context, one each for Production and NonProduction environments. This is adjustable if you want a finer-grained taxonomy with higher levels of isolation.

Workloads aligned to Domain Contexts
Expand image

Team Autonomy and Governance

Using DDC, your organization can grant autonomy to teams to enable innovation within guardrails. Leveraging key concepts from team topologies, stream-aligned teams can be self-sufficient while platform teams can focus on highly-available services used by the stream-aligned teams. From a governance perspective, policies and controls are automatically enforced downwards while costs and compliance are automatically enforced upwards.

Workloads aligned to Domain Contexts
Expand image
3
Step three

Align Workloads to Bounded Contexts

Map Workloads

Organize all your cloud workloads around the bounded context that makes the most sense, based on your business model. We prefer a workshop approach that promotes discussion and collaboration.

Workloads aligned to Domain Contexts
Expand image

Identify Deployable Components

For each context, identify the independently deployable components for each workload. For our customer’s Order context, they used Azure Resource Groups for each independently deployable application or service, which then contained Azure Resources.

Workloads aligned to Domain Contexts
Expand image
4
Step four

Migrate Workloads

Works for Greenfield or Brownfield

Now that we have identified where each workload will run, it was time to begin moving them into the right Account or Subscription. Our customer was new to Azure (greenfield), but this works equally well if you are re-architecting your existing cloud platform (brownfield). A repeatable and scalable process like our agile Cloud Migration Approach is especially helpful during migrations.

5
Step five

Inspect and Adapt

Evolve your Cloud Architecture

Your cloud architecture is not a static artifact, the design will continue to evolve over time as your business changes and new technologies emerge. Methods like GitOps work nicely alongside DDC to keep your cloud infrastructure flexible and extensible over time and continually aligned with your business model.

Looking for a Trusted Partner to Guide Your Cloud Migration Efforts?

Click below for additional guidance around implementing any of the above measures within your organization.

Get connected with an expert