Digital and Cloud Scale Architecture · Module 1

Domains and bounded contexts

Glossary Tip.

55 min 3 outcomes Software Development and Architecture Advanced

Previously

Start with Software Development and Architecture Advanced

Event driven systems, CQRS, integration patterns, observability and digitalisation strategy across whole organisations.

This module

Domains and bounded contexts

Glossary Tip.

Advanced patterns and distribution

Glossary Tip.

Progress

Mark this module complete when you can explain it without rereading every paragraph.

Why this matters

When contexts blur, systems become expensive to change.

What you will be able to do

1 Explain domain and bounded context using practical examples
2 Spot overloaded language and split meanings cleanly
3 Sketch a context map that shows ownership and contracts

Before you begin

Comfort with earlier modules in this track
Ability to explain trade-offs and risks without jargon

Common ways people get this wrong

Boundary denial. When boundaries are denied, coupling grows and delivery slows.
Shared database coupling. Shared databases often break bounded contexts by stealth.

Main idea at a glance

Diagram

Stage 1

Customer context

Owns profile management, consent preferences, and contact methods. Keeps customer language separate from billing semantics.

I think customer contexts often fail because teams blur 'bill payer' with 'occupier'. Make language explicit first.

Domain Driven Design - Bounded Contexts

Interactive lab

Glossary Tip

This module includes an interactive practice component. Open the deeper tool or workspace step when you want to test the idea rather than only read it.

When contexts blur, systems become expensive to change. Clear language and boundaries protect velocity.

Diagram

Stage 1

Command Handler

Receives write commands and validates request semantics before passing to the aggregate.

I think command handlers should be thin and stateless, keeping logic in the aggregate.

CQRS and Event Sourcing Pattern

Bounded context responsibilities

Split contexts where language and ownership diverge, then enforce contracts between them.

Customer context

Own profile, consent, and contact semantics without billing leakage.
Billing context

Own invoice rules, payment lifecycle, and tariff policy evolution.
Operations context

Own outage events, field updates, and service restoration workflows.

Worked example. “Customer” means two different things and your system pays the price

One team uses “customer” to mean “bill payer”. Another uses it to mean “occupier”. Both are reasonable in isolation. The problem is when services silently mix them. You then get strange behaviour: wrong notifications, bad reporting, and angry users.

Common mistakes in bounded contexts

Bounded context mistakes to avoid

Context boundaries fail when meaning and ownership are vague.

Naming contexts after systems

Name contexts from domain meaning and decision authority, not existing platform names.
Sharing one database by default

Shared storage often hides ownership conflicts and creates risky coupling over time.
Centralising language ownership

Each context must own its own terms and publish clear contracts for cross-context integration.

Verification. A quick boundary test

Boundary verification checks

Run these checks to validate context quality before scaling teams.

Test overloaded terms

Write explicit definitions and verify they do not overlap across contexts.
Trace breakage path

Identify which teams fail first when a model changes and why.
Confirm clear ownership

Assign accountable owners for each context’s data model and contracts.

Reflection prompt

If you split your current system into contexts, where are the natural seams and why.

How to use Advanced

At this point, you are designing for the organisation you will become in two years, not the team you have today.

Good practice: Design boundaries around language and ownership, not just code. If the ownership is unclear, the architecture will drift.
Bad practice: Over engineering to avoid making a decision. Complexity does not remove risk. It often hides it.
Best practice: Pair every design with an operational story. Signals, alerts, runbooks, and rollback. If it cannot be operated, it is not finished.

Mental model

Domains and bounded contexts

Bounded contexts keep meaning local so change does not break everything.

1

Domain
2

Context boundary
3

Model
4

Interfaces

Assumptions to keep in mind

Meaning is local. If you force one meaning everywhere, teams spend months translating anyway.
Interfaces are explicit. Interfaces are how contexts cooperate without merging.

Failure modes to notice

Boundary denial. When boundaries are denied, coupling grows and delivery slows.
Shared database coupling. Shared databases often break bounded contexts by stealth.

Check yourself

Quick check. Domains and bounded contexts

0 of 9 opened

Why does language matter in architecture

It keeps teams aligned on meaning and boundaries.

What is a bounded context

A boundary where terms and models have one clear meaning.

Scenario. Two teams both own 'Customer' but mean different things. What do you do first

Make the meanings explicit, split the bounded contexts, and define the contract between them. Do not merge the models just to reduce arguments.

Why do blurred contexts slow change

Because responsibilities and data meaning drift.

What should define a domain

The core business problem the system serves.

What is ubiquitous language

Shared words used consistently by teams and domain experts.

Why do contexts reduce coupling

They limit how much one team must know about another.

What is a sign of overloaded context

Too many features or teams sharing one model.

How does this connect to Intermediate styles

Styles give structure, contexts give meaning and ownership.

Artefact and reflection

Artefact

A context map for one realistic system and a short contract note

Reflection

Where in your work would explain domain and bounded context using practical examples change a decision, and what evidence would make you trust that change?

Optional practice

Group features into contexts and spot overloaded boundaries.