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

1. Underlying Mechanism

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

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

3. Production Failure Modes

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

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

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

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)

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