Software architecture · Level 2: Structure · Module 08a of 46

Domain-Driven Design: strategic design

Module 08 found components by following workflows. Domain-Driven Design (DDD), from Eric Evans' 2003 book, goes further: it finds the boundaries where words change meaning, decides which parts of the business deserve your best engineers, and names the relationship between every pair of teams and models. Those boundaries, called bounded contexts, are the most reliable place to draw service and team lines.

1. The idea

In a hospital, "patient" means a bed and a diet to the ward, a set of test results to the lab, and an insurance claim to billing. Each department keeps its own forms with the fields it needs, and a referral note translates between them. Nobody tries to design one form that serves everyone; it would have 300 fields and every change would need every department's approval.

Strategic DDD is four ideas.

Ubiquitous language. Developers and domain experts use the same words, with the same meanings, in conversation, in documents and in the code. If the business says "policy lapses", the code says policy.lapse(), not setStatus(3).
Subdomains are parts of the business (the problem). They aren't equally valuable, so they don't deserve equal effort (below).
Bounded contexts are parts of the solution: a boundary inside which one model and one language hold. "Order" can mean a basket in Sales and a pick list in Fulfilment; each context has its own Order. Ideally one team owns a context, and a context is a natural candidate for a service or a module.
Context maps show how contexts relate: who depends on whom, and how models are translated at each border.

Three kinds of subdomain

Kind	What it is	What to do	Example (food delivery)
Core	What makes the company different and wins customers	Build it in-house, with your best people and the richest model	Courier dispatch and delivery-time prediction
Supporting	Needed and specific to you, but not a differentiator	Build it simply, or have another team or partner build it	Restaurant menu management
Generic	Every company needs it and it's a solved problem	Buy or use a product or open-source tool	Payments, login, email delivery

Context-map patterns

The DDD Crew's reference lists nine patterns. Each answers: when two contexts integrate, whose model wins, and who translates?

Pattern	What it means	Use it when
Anticorruption layer	The downstream context translates the upstream model into its own	The upstream model is messy, legacy or a vendor's
Open-host service	The upstream offers a well-defined API for anyone to use	Many consumers need the same data
Published language	A documented shared format (a schema, a standard)	Paired with open-host; industry formats
Conformist	The downstream simply adopts the upstream's model	The upstream model is good enough and you can't influence it
Customer–supplier	Upstream plans with downstream's needs in mind	Teams in one organisation with aligned priorities
Partnership	Two teams plan and release together	Tightly linked features, for a while
Shared kernel	A small, explicitly shared piece of model and code	Rarely: it couples both teams' releases
Separate ways	No integration; each solves it alone	Integration costs more than duplication
Big ball of mud	A system with no clear model: mark it and isolate it	Describing legacy honestly

2. How it works

An anticorruption layer in front of a legacy CRM

The Orders context needs to know whether a customer may buy on credit. The answer lives in a 20-year-old CRM. Watch where the translation happens, and what a CRM upgrade costs.

Finding contexts with Event Storming

Event Storming (Alberto Brandolini) is a workshop: domain experts and developers put everything that happens in the business on a wall as past-tense events, in time order. Where the language changes, a boundary is near.

3. Try it yourself

Classify the subdomains

A food-delivery company. For each capability, choose core, supporting or generic. You'll see the usual answer and why; your company's strategy may reasonably differ.

4. Trade-offs

One model vs many

One enterprise model avoids duplicate fields and couples every team to every change. A model per context duplicates a few fields (name, address) and lets each evolve alone. Share identifiers, not models.

Translate vs conform

An anticorruption layer costs code and a hop, and protects your model from an upstream you don't control. Conforming is free today and expensive when the upstream changes.

Build vs buy, by subdomain

Building a generic subdomain spends your best people on a solved problem. Buying a core one hands your differentiator to a vendor every competitor can also buy.

Contexts vs services

A bounded context is a model boundary, not a deployment decision. One context can be one module in a monolith (Module 11) or one service. Split deployment only when characteristics differ (Module 09).

5. In real projects

Listen for words that mean two things. "Account" in a bank (a login? a ledger?), "product" in retail (a catalogue entry? a stock unit?), "booking" in travel. Each double meaning is a context boundary waiting to be drawn.

Draw the context map of what exists, not of what you wish. Mark the big balls of mud, the conformist relationships you didn't choose, and the places where five teams read one database. That map is often the most useful single architecture diagram in a company.

Contexts and teams. One team per context keeps the language consistent. A context owned by three teams drifts into three dialects; a team owning eight contexts can't hold all eight models in its head (Module 09a).

Say it in the interview

Two-sentence answers

"How do you decide service boundaries?" I start from bounded contexts: where the business's words change meaning and where different teams own the rules. Then I merge or split by architecture characteristics and coupling.
"How would you integrate with this legacy system?" Behind an anticorruption layer that translates its model into ours, so its codes and quirks stay at the border and an upgrade changes one adapter.
"Should we build or buy this?" Depends on the subdomain: build the core that differentiates us, buy the generic, keep supporting parts simple.

Red flags interviewers notice

One "Customer" or "Product" service that every other service calls for every field.
Bounded contexts drawn around database tables (entities) instead of language and behaviour.
Building login, payments or email from scratch "for control".

6. Remember it

Memory hook: "Where the word changes, the border goes"Draw a bounded context wherever the same word starts to mean something different, and translate at the border.

How this hook works: what "where the word changes, the border goes" means

What the slogan means, phrase by phrase

"Where the word changes": The ubiquitous language shifts: "order" stops meaning a basket and starts meaning a pick list.
"the border goes": A bounded context boundary, with a context-map pattern (often an anticorruption layer or published language) on it.

Why this picture fits: real borders sit where languages change, and travellers need translation and a passport check there, not everywhere.

The story → the concept

The hospital	DDD
Ward, lab, billing	Bounded contexts
Each department's own patient form	A model per context
The referral note	Translation at the border (anticorruption layer)
The 300-field universal form	An enterprise-wide shared model

The trap it saves you from

Building one model of the whole business that every team must agree on before anyone can change it.

7. Common mistakes

Contexts per entityA Customer service, an Order service, a Product service: that's the entity trap from Module 08 with DDD names. Contexts follow behaviour and language, and each contains several entities.

DDD tactics without strategyAggregates and repositories (Module 08b) inside one giant context don't fix a model that means different things to different teams.

The accidental conformistUsing a vendor's or legacy system's codes directly throughout your code. Every upstream change becomes your change.

Shared kernels that growA "small" shared library of models that ten teams depend on is a release bottleneck. Keep it tiny or remove it.

8. Design exercise (30 minutes)

Events on a wall (10 min). For a business you know, write 15 past-tense events in time order: "Quote requested", "Policy issued", and so on.
Find the borders (10 min). Mark where words change meaning or ownership changes. Name each context, and mark it core, supporting or generic.
Draw the map (10 min). Connect the contexts. Label each line with a context-map pattern and say which side translates.

9. Self-check quiz

What is a bounded context?

It's a model boundary. It may become a service or a module; that's a separate decision.

Your context must use a legacy system whose model is confusing and changes on the vendor's schedule. Which pattern protects you?

The layer translates their model into yours, so their changes stop at the border.

Identity and login is a generic subdomain for most companies. What does that suggest?

Generic subdomains are solved problems; your best people belong on the core.

In Event Storming, what usually signals a context boundary?

Shifts in meaning or ownership, often around pivotal events, mark the borders.

Must every bounded context be a separate microservice?

Contexts can be modules in one deployment. Split when characteristics or teams require it.

10. Go deeper

Resource	Time	Why
Context mapping (DDD Crew)	20 min	All nine patterns and three team relationships, with a printable cheat sheet.
Bounded Context (Martin Fowler)	10 min	Why one model per context beats one model for everything.
EventStorming (Alberto Brandolini)	reference	The workshop formats and how to run them.
DDD Reference (Eric Evans)	reference	Short definitions of every DDD pattern, from the author of the original book.