Strategic DDD and Context Mapping Patterns

What 'strategic' means

DDD has two halves. Tactical: how you build inside a Bounded Context (entities, aggregates, repositories). Strategic: how you carve a system into BCs and how they relate.

Strategic DDD answers: what are the major subdomains? Which are core to competitive advantage? Where to draw context boundaries? How do contexts integrate — sync, async, shared model, ACL? Who owns what?

Without strategic clarity, tactical work goes wrong: brilliant aggregates in the wrong context, expensive DDD machinery for generic subdomains you should have bought.

Subdomains — core, supporting, generic

Core: company's competitive advantage. Custom-built; best engineers and deepest DDD modeling. Netflix recommendation engine, Stripe payment routing, Google ranking.

Supporting: necessary but not differentiating. Custom or customized OSS. Order management for e-commerce, customer support tooling.

Generic: solved problems; no advantage in building yourself. Buy/SaaS/OSS — Auth0, Stripe, SendGrid. Authentication, payments, email, billing.

Investment rule: spend best engineering on Core. Commodity solutions for Generic. Pragmatic about Supporting. Many DDD projects fail by treating all subdomains as equally deserving deep modeling.

Context map

Diagram showing which contexts integrate, direction (upstream/downstream), pattern (Customer/Supplier, ACL, OHS), team relationships. Wall poster or simple diagram in architecture docs.

The eight context mapping patterns

Upstream-downstream:

1. 1
   Customer/Supplier — downstream has formal influence on upstream. Healthy in-org relationship
2. 2
   Conformist — downstream adopts upstream's model as-is. Cheap; works when upstream well-designed and you have no leverage
3. 3
   Anti-Corruption Layer (ACL) — downstream wraps upstream behind translation. Used when upstream has different vocabulary, unstable, or legacy
4. 4
   Open Host Service (OHS) — upstream publishes stable well-documented API designed for many consumers
5. 5
   Published Language — shared versioned schema (Avro, Protobuf, OpenAPI). Often paired with OHS

Mutual / no integration:

1. 6
   Shared Kernel — small shared model both contexts depend on. Powerful but coupling-heavy; only with trusted partners and stable models
2. 7
   Partnership — two contexts mutually depend; succeed or fail together. Coordinate releases
3. 8
   Separate Ways — no integration. Each context goes its own way; users tolerate duplication. Sometimes right when integration cost > benefit

How to choose a pattern

Three factors:

1. 1
   Power dynamic: you have leverage → Customer/Supplier or OHS. They have leverage / external → Conformist or ACL
2. 2
   Upstream stability: stable → Conformist cheap. Unstable / different vocabulary → ACL necessary
3. 3
   Strategic importance: Core must stay clean → always ACL. Supporting + generic upstream → maybe Conformist

Decision tree: external/legacy upstream → ACL. Sister team with clean stable API → Conformist or Customer/Supplier. Upstream willing to publish stable API for many consumers → OHS + Published Language. Two contexts share a few VOs → Shared Kernel (keep small). Barely interact and high cost → Separate Ways.

Conway's Law in action

Conway: organizations design systems mirroring communication structure. Strategic DDD acknowledges directly.

• BC boundaries should align with team boundaries; each BC has one owning team
• Integration pattern reflects team relationship: trusting partnership → Customer/Supplier; arms-length → ACL or OHS
• One team owning two BCs → boundary suspect
• Two teams owning one BC → expect fragmentation

Inverse Conway maneuver: organize teams to make desired architecture natural.

Subdomain type drives pattern

Core + upstream → ACL or OHS+ACL. Protect the model; competitive advantage; mapping cost justified. Supporting + upstream → Conformist or Customer/Supplier. Pragmatic. Generic → Conformist or Buy + thin ACL. Minimal investment; off-the-shelf wins.

Many teams invert this: build custom ACL-laden integration with their Generic auth provider while letting Core conform to legacy ERP vocabulary.

Common mistakes

• No subdomain classification — BCs treated equally, no investment clarity
• Conformist with legacy upstream — pulls legacy vocabulary into your Core
• Shared Kernel grows organically — starts Money + CustomerId, six months later 200-class shared library both teams hate
• Partnership without coordination — mutual chaos
• Open Host Service without versioning — breaking changes ripple
• No context map — teams discover integration patterns through painful incidents
• One team owning many BCs — fragmented or overstretched
• Building DDD scaffolding for a Generic subdomain — aggregate + repository for what should have been a Stripe webhook handler

Recommendation

Start strategic DDD by classifying subdomains (Core/Supporting/Generic) so you know where to invest. Draw Bounded Context boundaries aligned with team ownership. Document integrations in a context map using the eight patterns: ACL whenever upstream is external/legacy or has different vocabulary; OHS + Published Language when upstream serves many consumers; Conformist only when upstream is stable, well-designed, and the cost of conforming is acceptable; Shared Kernel only with trusted partners and only for stable, small models. Conway's Law is a constraint: design boundaries that match team boundaries, or change the team structure. Spend deep DDD effort on Core subdomains; buy or commodity-source Generic ones.