Skip to main content

> strategic_domain-driven_design:_context_mapping,_shared_kernel_&_customer-supplier_relationships

Strategic Domain-Driven Design: Context Mapping, Shared Kernel & Customer-Supplier Relationships

How do large engineering organizations map organizational power dynamics and architectural integration patterns across bounded contexts without causing distributed monolith coupling?

Staff/Principal (L6+)

⚡THE SHORT ANSWER

In Domain-Driven Design (DDD), defining isolated Bounded Contexts is only half the battle; the real complexity lies in how contexts relate, integrate, and exchange data. If two teams share a database table or publish unversioned internal models, they silently degenerate into a tightly coupled distributed monolith. Eric Evans defined Context Mapping to explicitly formalize architectural and team boundaries:

1

Shared Kernel: Two contexts explicitly share a small, tightly controlled subset of code/domain model, requiring joint approval for any change.

2

Customer-Supplier (Upstream/Downstream - U/D): The Upstream supplier team must deliver features requested by the Downstream customer team.

3

Conformist: Downstream has no leverage and must conform 100% to Upstream's model.

4

Anti-Corruption Layer (ACL): Downstream builds a translation layer to protect its domain purity from a messy Upstream model.

5

Open Host Service (OHS) / Published Language (PL): Upstream exposes a stable, documented public protocol (e.g. REST/Protobuf) for multiple consumers.

Engineering Handbook & Failure Dynamics

6-Dimensional Architecture Breakdown

⚙️1. Underlying Mechanism

Execution

Context mapping operates through 7 standardized relationship topologies:

1

Shared Kernel (SK): Shared binary library or schema with joint commit governance.

2

Upstream/Downstream (U o D): Flow of influence where changes in U force changes in D.

3

Customer-Supplier (C/S): Upstream prioritizes Downstream's feature roadmap.

4

Conformist (CF): Downstream adopts Upstream's exact models with zero translation.

5

Anti-Corruption Layer (ACL): Downstream translates Upstream entities into its own domain language via adapters.

6

Open Host Service (OHS) & Published Language (PL): Standardized public API and schema (e.g. OpenAPI, JSON Schema).

7

Separate Ways: Deliberately choosing zero software integration because cost exceeds business value.

🎯2. Appropriate Use Context

Scope

Enterprise service-oriented architecture (SOA), microservices migrations, legacy monolith modernization, and M&A technical integration.

⚠️3. Production Failure Modes

P0 Risk
  • ✓

    Allowing a Shared Kernel to grow uncontrollably until it contains 50% of the company's business logic, creating deployment lockstep

  • ✓

    adopting Conformist integration with a poorly designed legacy system, polluting modern services with legacy technical debt

📡4. Diagnostic Signals & Telemetry

Telemetry
  • ✓

    Teams waiting on another team's deployment before they can release their own PR

  • ✓

    shared database tables being modified by 4 different microservices

  • ✓

    lack of architectural diagrams showing Upstream/Downstream power dynamics

🛡️5. Prevention & Safeguards

Safeguards
  • ✓

    Draft explicit Context Maps in architectural decision records (ADRs)

  • ✓

    enforce Anti-Corruption Layers (ACL) whenever integrating with legacy or third-party platforms

  • ✓

    strictly restrict Shared Kernels to immutable core value objects

⚖️6. Architectural Trade-offs

Trade-off

Context mapping establishes crystal-clear service ownership and prevents architectural coupling, but requires continuous cross-team governance and translation layer maintenance.

📋

Case Study (TinyCTO In-Field Example)

REAL-WORLD TELEMETRY

A retail company's modern Recommendation microservice integrated with a 15-year-old COBOL Inventory monolith. Initially, the team conformed directly, importing the legacy INV_ITEM_MST_V1 schema. When the legacy team renamed column codes, the recommendation engine crashed in production. The team introduced an Anti-Corruption Layer (ACL): an adapter service consumed the legacy feed and translated it into a clean, modern ProductCatalog domain model. Subsequent breaking changes in the COBOL monolith were absorbed entirely within the ACL adapter, with zero downtime or code changes in the recommendation engine.

Interactive Concept Drills

2 Cards
Q1

What is an Anti-Corruption Layer (ACL) in DDD Context Mapping?

A translation layer between two bounded contexts that converts external foreign models into the internal domain's clean ubiquitous language, protecting it from external conceptual pollution.
Q2

Why is a Shared Kernel risky if not strictly governed?

Because changes made by one team can immediately break the other team, creating tight deployment coupling and destroying microservice independence.

Strategic Domain-Driven Design: Context Mapping, Shared Kernel & Customer-Supplier Relationships — Technical FAQ

What does 'Upstream' (U) and 'Downstream' (D) mean in Context Mapping?

Upstream (U) is the provider whose changes influence Downstream; Downstream (D) is the consumer whose software is affected by Upstream's decisions.

What is an Open Host Service (OHS)?

A protocol or public API (REST/gRPC) provided by an upstream subsystem that gives access to multiple downstream systems through a stable published language.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸

    Context Mapping defines strategic integration and organizational relationships between bounded contexts.

  • ▸

    Use Anti-Corruption Layers (ACL) to shield modern domain logic from legacy models.

  • ▸

    Shared Kernels must be strictly limited to prevent deployment lockstep.

  • ▸

    Upstream/Downstream mappings make power dynamics and technical dependencies explicit.

Common Misconceptions

  • ✗

    Yanılgı: Microservices should share common database tables to stay in sync (Gerçek: Database sharing creates catastrophic distributed monolith coupling and schema deadlock).

  • ✗

    Yanılgı: Every integration requires an ACL (Gerçek: If the upstream API is well-designed and stable (OHS/PL), direct consumption or Conformist may be acceptable).

Decision & Governance Guidance

Document explicit Context Maps in architecture blueprints to clarify team contracts and isolate domain models across enterprise microservices.

Authoritative Sources & Standards

Technical terms on this page