Bounded Contexts - Learning Module

Loading content...

0/246

Context Mapping

The Language of Context Relationships

Once we've identified bounded contexts and drawn their boundaries, we face the next challenge: how do these contexts relate to each other? Real systems don't consist of isolated silos. Contexts must communicate, share information, and coordinate activities. The patterns they use to do this significantly impact system maintainability, team autonomy, and evolutionary flexibility.

Context Mapping is the DDD discipline of explicitly identifying and documenting the relationships between bounded contexts. It provides a vocabulary for discussing these relationships precisely, elevating discussions from vague generalities ('they integrate somehow') to specific, actionable patterns ('Sales is upstream of Fulfillment with an Open Host Service').

This page introduces the complete vocabulary of context relationships—the patterns that describe how bounded contexts influence, depend on, and integrate with each other.

What You Will Learn

By the end of this page, you will understand the full taxonomy of context relationship patterns, know when to apply each pattern, and be able to create comprehensive context maps for complex systems. You'll gain a precise vocabulary for discussing integration strategies.

The Context Map

A Context Map is a visual and conceptual representation of all bounded contexts in a system and the relationships between them. It serves as a strategic document that:

Reveals the big picture — Shows how the entire system is structured at the domain level
Documents integration approach — Captures how contexts communicate and share data
Highlights power dynamics — Shows which contexts influence which, and who accommodates whom
Guides team coordination — Clarifies which teams need to collaborate and how
Identifies risks — Exposes tight coupling, single points of failure, and integration bottlenecks

The context map isn't just documentation—it's a strategic thinking tool. Creating one forces you to make implicit assumptions explicit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Context Map Elements
═════════════════════════════════════════════════════════════════════════════════
 
1. BOUNDED CONTEXTS (Boxes)
   ┌─────────────────────────┐
   │     CONTEXT NAME        │
   │     ────────────        │
   │     Team: TeamName      │  ← Ownership
   │     Type: Core/Support  │  ← Strategic classification
   └─────────────────────────┘
 
2. RELATIONSHIPS (Lines/Arrows)
   
   Context A ──────→ Context B     Direction indicates influence/dependency
   Context A ←─ACL── Context B     Pattern label on the line
   Context A ═══════ Context B     Partnership (equal influence)
 
3. RELATIONSHIP PATTERNS (Labels)
   
   Pattern                     Symbol    Description
   ───────────────────────────────────────────────────────────────────────
   Partnership                   P        Mutual cooperation
   Shared Kernel                 SK       Shared model subset
   Customer-Supplier             C/S      Downstream influences upstream
   Conformist                    CF       Downstream accepts upstream model
   Anti-Corruption Layer         ACL      Translation layer protects context
   Open Host Service             OHS      Published API for multiple consumers
   Published Language            PL       Well-documented shared format
   Separate Ways                 SW       No integration (deliberate)
   Big Ball of Mud               BBoM     No clear boundaries (reality)
 
4. EXTERNAL SYSTEMS
   ╔═════════════════════════╗
   ║   EXTERNAL SYSTEM       ║   Double border indicates
   ║   (Third Party)         ║   external/legacy system
   ╚═════════════════════════╝

Context maps should be living documents. As the system evolves, the map must evolve with it. Many teams display the context map prominently (physical or virtual wall) and update it as part of architectural reviews.

Partnership

Partnership describes a relationship where two contexts have a mutual dependency and the teams coordinate closely to meet shared objectives. Neither team dominates; both have roughly equal influence over the integration.

Partnership Characteristics

•Joint Planning — Features affecting both contexts are planned together. Neither team commits to work that impacts the other without agreement.
•Synchronized Releases — Changes that affect the integration point are coordinated so both contexts update together.
•Shared Success Criteria — Both teams measure success by joint outcomes, not individual context metrics.
•High Communication — Frequent synchronization meetings, shared channels, and direct collaboration.

When to Use Partnership
Use When	Avoid When
Both teams are in the same organization and can coordinate easily	Teams are in different organizations with different priorities
Features frequently require changes to both contexts simultaneously	Contexts have independent release cycles and change for different reasons
Teams have compatible goals and incentives	Teams have conflicting priorities or compete for resources
The integration is core to both contexts' value proposition	Integration is peripheral to one or both contexts

Partnership is Expensive

Partnership has high coordination overhead. It works only when both teams truly benefit from close collaboration. If one team is always accommodating the other, it's not partnership—it's an unacknowledged upstream/downstream relationship that should be formalized.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
E-Commerce Platform: Shopping Cart + Pricing Partnership
═════════════════════════════════════════════════════════════════════════════════
 
        ┌─────────────────────┐                ┌─────────────────────┐
        │   SHOPPING CART     │   Partnership  │      PRICING        │
        │   ─────────────     │ ══════════════ │    ────────         │
        │   Team: Cart Eng    │                │   Team: Pricing Eng │
        │   Owns: Cart logic  │                │   Owns: Prices      │
        └─────────────────────┘                └─────────────────────┘
                 │                                      │
                 └──────────────────┬───────────────────┘
                                    │
                 Joint Planning Sessions Every Sprint
                 ─────────────────────────────────────
                 • Cart needs real-time price updates
                 • Pricing needs cart context for discounts  
                 • Both teams align on API changes
                 • Synchronized releases for promotions
 
Why Partnership Works Here:
• Both contexts are core to checkout experience
• Price calculation requires cart content
• Cart display requires current prices
• Changes are frequent and bidirectional
• Teams share the goal: maximize conversion

Shared Kernel

Shared Kernel is a pattern where two contexts share a small subset of domain model code that is jointly owned. Both teams can modify this shared code, and any changes must be coordinated.

The shared kernel typically includes:

Core value objects (Money, CustomerId, Email)
Shared enumerations and types
Common domain events
Fundamental interfaces

Importantly, the shared kernel is as small as possible. It represents the absolute minimum that genuinely needs to be shared, not a dumping ground for convenience.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
// ═══════════════════════════════════════════════════════════════════════════
// SHARED KERNEL: Minimal types shared across bounded contexts
// Package: @company/shared-kernel
// ═══════════════════════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────────────────────────
// VALUE OBJECTS: Fundamental types with no business logic
// ─────────────────────────────────────────────────────────────────────────────
 
export class CustomerId {
    private constructor(private readonly value: string) {
        if (!value || value.length === 0) {
            throw new Error("CustomerId cannot be empty");
        }
    }
    
    static create(value: string): CustomerId {
        return new CustomerId(value);
    }
    
    static generate(): CustomerId {
        return new CustomerId(crypto.randomUUID());
    }
    
    equals(other: CustomerId): boolean {
        return this.value === other.value;
    }
    
    toString(): string {
        return this.value;
    }
}
 
export class Money {
    private constructor(
        private readonly amount: number,
        private readonly currency: Currency
    ) {
        if (amount < 0) {
            throw new Error("Money amount cannot be negative");
        }
    }
    
    static of(amount: number, currency: Currency): Money {
        return new Money(amount, currency);
    }
    
    add(other: Money): Money {
        if (!this.currency.equals(other.currency)) {
            throw new Error("Cannot add money of different currencies");
        }
        return new Money(this.amount + other.amount, this.currency);
    }
    
    // Other money operations...
}
 
export type Currency = 'USD' | 'EUR' | 'GBP' | 'JPY';
 
// ─────────────────────────────────────────────────────────────────────────────
// INTEGRATION EVENTS: Events that cross context boundaries
// ─────────────────────────────────────────────────────────────────────────────
 
export interface IntegrationEvent {
    readonly eventId: string;
    readonly occurredAt: Date;
    readonly eventType: string;
}
 
export interface CustomerRegistered extends IntegrationEvent {
    eventType: 'CustomerRegistered';
    customerId: string;  // Note: string, not CustomerId (for serialization)
    email: string;
    registeredAt: Date;
}
 
export interface OrderPlaced extends IntegrationEvent {
    eventType: 'OrderPlaced';
    orderId: string;
    customerId: string;
    totalAmount: number;
    currency: Currency;
    placedAt: Date;
}
 
// ─────────────────────────────────────────────────────────────────────────────
// GOVERNANCE: Rules for shared kernel modification
// ─────────────────────────────────────────────────────────────────────────────
 
/**
 * SHARED KERNEL GOVERNANCE RULES:
 * 
 * 1. Any change requires approval from ALL teams using this kernel
 * 2. Changes must be backward compatible OR coordinated release
 * 3. No business logic—only fundamental types and events
 * 4. Keep it minimal—if in doubt, don't share
 * 5. Semantic versioning with major bumps for breaking changes
 * 6. Comprehensive test coverage required
 */

Shared Kernel Risks

Shared kernels create tight coupling. Every change requires multi-team coordination. If the shared kernel grows too large, it becomes a distributed monolith hidden inside a package. Use sparingly and keep it minimal. When in doubt, duplicate instead of share.

Customer-Supplier

Customer-Supplier (also called Upstream-Downstream) describes a relationship where one context (upstream/supplier) provides data or services that another context (downstream/customer) consumes. The key distinction from other patterns is that the downstream team has influence over the upstream team's priorities.

In a customer-supplier relationship:

The upstream context provides something the downstream context needs
The downstream team can negotiate requirements and influence the upstream team's roadmap
There's a formal agreement (explicit or implicit) about what the upstream will provide
The relationship is acknowledged and managed by both teams

Upstream (Supplier)

•Produces data/events
•Defines the interface
•Has more power by default
•Must consider downstream needs
•Provides capability others depend on

Downstream (Customer)

•Consumes data/events
•Adapts to the interface
•Depends on upstream stability
•Can negotiate requirements
•Consumes capability others provide

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Order Processing: Sales (Upstream) → Fulfillment (Downstream)
═════════════════════════════════════════════════════════════════════════════════
 
        ┌─────────────────────┐                ┌─────────────────────┐
        │       SALES         │   Customer/    │    FULFILLMENT      │
        │   (Upstream)        │   Supplier     │    (Downstream)     │
        │   ─────────────     │ ──────────────→│    ────────────     │
        │   Produces:         │                │   Consumes:         │
        │   • OrderPlaced     │                │   • OrderPlaced     │
        │   • OrderModified   │                │                     │
        │   • OrderCancelled  │                │   Needs:            │
        └─────────────────────┘                │   • Shipping address│
                                               │   • Line items      │
                                               │   • Priority level  │
                                               └─────────────────────┘
 
Customer-Supplier Agreement:
────────────────────────────────────────────────────────────────────────────
• Fulfillment can request new fields in OrderPlaced event
• Sales commits to including requested fields if reasonable
• Sales notifies Fulfillment before any breaking changes
• Both teams review integration needs quarterly
 
This differs from Conformist because:
────────────────────────────────────────────────────────────────────────────
• Fulfillment CAN request changes (vs. must accept what's given)
• Sales WILL consider Fulfillment's needs (vs. ignoring downstream)
• There IS a relationship and communication (vs. one-way consumption)

Healthy Customer-Supplier Dynamics

The key to successful customer-supplier relationships is explicit negotiation. The downstream team should articulate their needs clearly. The upstream team should consider those needs genuinely. Regular sync meetings (monthly or quarterly) keep the relationship healthy. Without explicit communication, customer-supplier degrades into conformist.

Conformist

Conformist describes a relationship where the downstream context accepts the upstream context's model as-is, without any translation or negotiation. The downstream team 'conforms' to whatever the upstream provides.

This pattern typically occurs when:

The upstream is an external system or third-party API
The upstream team is unresponsive to downstream needs
The cost of translation outweighs the benefits
The upstream model is actually a good fit for downstream needs

Conformist Implications

•Model Leakage — The upstream model concepts leak into the downstream context. If the upstream calls it 'CustomerAccount', the downstream uses that term even if 'Client' fits better.
•Change Vulnerability — When the upstream changes, the downstream must change too. There's no insulation layer.
•Vocabulary Pollution — The downstream's ubiquitous language includes foreign terms from the upstream, potentially causing confusion.
•Coupling — Downstream depends directly on upstream's choices. Technology, naming, structure—all adopted wholesale.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// ═══════════════════════════════════════════════════════════════════════════
// CONFORMIST EXAMPLE: Our Billing context conforms to Stripe's model
// ═══════════════════════════════════════════════════════════════════════════
 
// We use Stripe's types directly in our domain layer
// This is conformist—we accept their model without translation
 
import Stripe from 'stripe';
 
// Our domain service uses Stripe's types directly
export class PaymentService {
    constructor(private stripe: Stripe) {}
    
    async processPayment(
        amount: number,
        currency: string,
        // Using Stripe's payment method type directly
        paymentMethod: Stripe.PaymentMethod,
        // Using Stripe's customer type directly
        customer: Stripe.Customer
    ): Promise<Stripe.PaymentIntent> {
        
        // We conform to Stripe's API structure
        const paymentIntent = await this.stripe.paymentIntents.create({
            amount,
            currency,
            customer: customer.id,
            payment_method: paymentMethod.id,
            confirm: true,
        });
        
        // We return Stripe's type, not our own
        return paymentIntent;
    }
}
 
// Our entities/aggregates reference Stripe concepts directly
interface OrderPayment {
    orderId: string;
    // Stripe's ID, not our own concept
    stripePaymentIntentId: string;  
    // Stripe's status enum, not our own
    status: Stripe.PaymentIntent.Status;
}
 
// ═══════════════════════════════════════════════════════════════════════════
// WHY CONFORMIST HERE?
// ═══════════════════════════════════════════════════════════════════════════
//
// 1. Stripe is a third-party—we cannot influence their model
// 2. Stripe's payment model is well-designed and widely understood
// 3. Translation would add complexity with little benefit
// 4. Our payment subdomain is not core—it's supporting
//
// RISKS ACCEPTED:
// - Stripe model changes force our code changes
// - "PaymentIntent" terminology leaks into our domain language
// - Tightly coupled to Stripe's SDK
//
// ═══════════════════════════════════════════════════════════════════════════

When Conformist is Acceptable

Conformist isn't always bad. When the upstream model is well-designed and stable (like major payment gateways), translation adds overhead without benefit. For non-core subdomains where the upstream model is 'good enough', conformist is pragmatic. Reserve translation efforts (ACL) for core domain protection.

Anti-Corruption Layer (ACL)

The Anti-Corruption Layer (ACL) is a translation mechanism that protects a bounded context from the conceptual model of another context (especially legacy systems or external systems). The ACL translates between models, ensuring the downstream context uses its own ubiquitous language without pollution from upstream concepts.

The ACL is the opposite of conformist: instead of accepting the foreign model, we actively translate it.

Anti-Corruption Layer Responsibilities

•Translate Data Structures — Convert external DTOs to internal domain objects and vice versa
•Map Vocabulary — Translate external terminology to internal ubiquitous language
•Handle Protocol Differences — Adapt between synchronous/asynchronous, REST/events, etc.
•Manage Versioning — Absorb external API version changes without propagating to domain
•Enforce Invariants — Validate incoming data meets internal domain rules
•Decouple Timing — Buffer external requests when internal processing differs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
// ═══════════════════════════════════════════════════════════════════════════
// ANTI-CORRUPTION LAYER: Protecting our domain from legacy system
// ═══════════════════════════════════════════════════════════════════════════
 
// ─────────────────────────────────────────────────────────────────────────────
// EXTERNAL SYSTEM (Legacy ERP we integrate with)
// ─────────────────────────────────────────────────────────────────────────────
 
// Legacy system's types (ugly, inconsistent naming, wrong concepts)
namespace LegacyERP {
    export interface CUST_MSTR {
        CUST_ID: string;
        CUST_NM: string;
        CUST_ADDR1: string;
        CUST_ADDR2: string;
        CUST_CITY: string;
        CUST_ST: string;
        CUST_ZIP: string;
        CUST_TEL: string;
        CUST_TAX_EXMPT: 'Y' | 'N' | null;
        CR_LMT: number;
        ACT_BAL: number;
        LST_ORD_DT: string;  // Date as string: "20240115"
    }
}
 
// ─────────────────────────────────────────────────────────────────────────────
// OUR DOMAIN MODEL (Clean, expressive, follows ubiquitous language)
// ─────────────────────────────────────────────────────────────────────────────
 
namespace CustomerDomain {
    export interface Customer {
        readonly id: CustomerId;
        readonly name: string;
        readonly address: Address;
        readonly phone: PhoneNumber;
        readonly taxStatus: TaxStatus;
        readonly creditProfile: CreditProfile;
        readonly lastOrderDate: Date | null;
    }
    
    export interface Address {
        readonly street1: string;
        readonly street2: string | null;
        readonly city: string;
        readonly state: string;
        readonly postalCode: string;
    }
    
    export type TaxStatus = 'TAXABLE' | 'EXEMPT' | 'UNKNOWN';
    
    export interface CreditProfile {
        readonly limit: Money;
        readonly currentBalance: Money;
        readonly availableCredit: Money;
    }
}
 
// ─────────────────────────────────────────────────────────────────────────────
// ANTI-CORRUPTION LAYER
// ─────────────────────────────────────────────────────────────────────────────
 
class CustomerAntiCorruptionLayer {
    
    /**
     * Translates legacy ERP customer to our domain model
     */
    translateFromLegacy(legacy: LegacyERP.CUST_MSTR): CustomerDomain.Customer {
        return {
            id: CustomerId.create(legacy.CUST_ID),
            name: this.normalizeName(legacy.CUST_NM),
            address: this.translateAddress(legacy),
            phone: PhoneNumber.parse(legacy.CUST_TEL),
            taxStatus: this.translateTaxStatus(legacy.CUST_TAX_EXMPT),
            creditProfile: this.translateCreditProfile(legacy),
            lastOrderDate: this.parseDate(legacy.LST_ORD_DT),
        };
    }
    
    /**
     * Translates our domain model back to legacy format (for updates)
     */
    translateToLegacy(customer: CustomerDomain.Customer): LegacyERP.CUST_MSTR {
        return {
            CUST_ID: customer.id.toString(),
            CUST_NM: customer.name.toUpperCase(),  // Legacy wants uppercase
            CUST_ADDR1: customer.address.street1,
            CUST_ADDR2: customer.address.street2 || '',
            CUST_CITY: customer.address.city,
            CUST_ST: customer.address.state,
            CUST_ZIP: customer.address.postalCode,
            CUST_TEL: customer.phone.toString(),
            CUST_TAX_EXMPT: this.translateTaxStatusToLegacy(customer.taxStatus),
            CR_LMT: customer.creditProfile.limit.getAmount(),
            ACT_BAL: customer.creditProfile.currentBalance.getAmount(),
            LST_ORD_DT: this.formatDateForLegacy(customer.lastOrderDate),
        };
    }
    
    private translateAddress(legacy: LegacyERP.CUST_MSTR): CustomerDomain.Address {
        return {
            street1: legacy.CUST_ADDR1.trim(),
            street2: legacy.CUST_ADDR2?.trim() || null,
            city: legacy.CUST_CITY.trim(),
            state: legacy.CUST_ST.trim(),
            postalCode: legacy.CUST_ZIP.trim(),
        };
    }
    
    private translateTaxStatus(flag: 'Y' | 'N' | null): CustomerDomain.TaxStatus {
        switch (flag) {
            case 'Y': return 'EXEMPT';
            case 'N': return 'TAXABLE';
            default: return 'UNKNOWN';
        }
    }
    
    private translateCreditProfile(legacy: LegacyERP.CUST_MSTR): CustomerDomain.CreditProfile {
        const limit = Money.of(legacy.CR_LMT, 'USD');
        const balance = Money.of(legacy.ACT_BAL, 'USD');
        return {
            limit,
            currentBalance: balance,
            availableCredit: limit.subtract(balance),
        };
    }
    
    private parseDate(dateStr: string): Date | null {
        if (!dateStr || dateStr === '00000000') return null;
        // Parse "20240115" format
        const year = parseInt(dateStr.substring(0, 4));
        const month = parseInt(dateStr.substring(4, 6)) - 1;
        const day = parseInt(dateStr.substring(6, 8));
        return new Date(year, month, day);
    }
}
 
// ─────────────────────────────────────────────────────────────────────────────
// USAGE: Repository uses ACL to fetch/save customers
// ─────────────────────────────────────────────────────────────────────────────
 
class CustomerRepository {
    constructor(
        private legacyClient: LegacyERPClient,
        private acl: CustomerAntiCorruptionLayer
    ) {}
    
    async findById(id: CustomerId): Promise<CustomerDomain.Customer | null> {
        // Fetch from legacy system
        const legacyData = await this.legacyClient.getCUST_MSTR(id.toString());
        if (!legacyData) return null;
        
        // Translate through ACL
        return this.acl.translateFromLegacy(legacyData);
    }
    
    async save(customer: CustomerDomain.Customer): Promise<void> {
        // Translate to legacy format
        const legacyData = this.acl.translateToLegacy(customer);
        
        // Save to legacy system
        await this.legacyClient.updateCUST_MSTR(legacyData);
    }
}

ACL for Core Domains

Invest in ACLs when protecting your core domain. The translation cost pays off by preserving your ubiquitous language and shielding your domain from external instability. For supporting or generic subdomains, conformist may be more cost-effective.

Open Host Service and Published Language

Open Host Service (OHS) describes an upstream context that provides a well-defined, stable API for multiple downstream consumers. Rather than point-to-point integrations, the upstream publishes a general-purpose interface that any consumer can use.

Published Language (PL) often accompanies OHS—it's a well-documented, shared format (schema, protocol) that consumers use to interact with the service. Together, OHS and PL enable scalable, decoupled integration.

Open Host Service

•General-purpose API for all consumers
•Stable, versioned interface
•Self-service onboarding
•Documentation and support
•Treats all consumers equally

Published Language

•Standardized data formats (JSON Schema, Protobuf)
•Well-documented event schemas
•Shared vocabulary definitions
•Versioning strategy documented
•Machine-readable specifications

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Open Host Service: Product Catalog API
═════════════════════════════════════════════════════════════════════════════════
 
                    ┌────────────────────────────────────────────┐
                    │          PRODUCT CATALOG CONTEXT           │
                    │          (Open Host Service)               │
                    │                                            │
                    │  Provides:                                 │
                    │  • REST API: /api/v1/products              │
                    │  • GraphQL: /graphql                       │
                    │  • Events: ProductCreated, ProductUpdated  │
                    │                                            │
                    │  Published Language:                       │
                    │  • OpenAPI 3.0 specification               │
                    │  • AsyncAPI event schemas                  │
                    │  • JSON Schema for all types               │
                    └────────────────────────────────────────────┘
                                         │
                    ┌────────────────────┴────────────────────┐
                    │                                         │
                    ▼                                         ▼
     ┌─────────────────────────┐           ┌─────────────────────────┐
     │   SEARCH CONTEXT        │           │   RECOMMENDATIONS       │
     │   (Downstream)          │           │   (Downstream)          │
     │                         │           │                         │
     │   Consumes:             │           │   Consumes:             │
     │   • ProductCreated      │           │   • ProductUpdated      │
     │   • ProductUpdated      │           │   • GET /products/{id}  │
     │   • ProductDeleted      │           │                         │
     │                         │           │   Uses Published        │
     │   Uses Published        │           │   Language: JSON Schema │
     │   Language: AsyncAPI    │           │                         │
     └─────────────────────────┘           └─────────────────────────┘
                    │
                    ▼
     ┌─────────────────────────┐
     │   ANALYTICS CONTEXT     │
     │   (Downstream)          │
     │                         │
     │   Consumes:             │
     │   • All product events  │
     │   • GET /products       │
     │                         │
     │   Uses Published        │
     │   Language: Protobuf    │
     └─────────────────────────┘
 
Benefits:
─────────────────────────────────────────────────────────────────────────────────
• Product Catalog doesn't need to know its consumers
• New consumers can self-onboard using documentation
• Schema changes go through semantic versioning
• Multiple protocol options (REST, GraphQL, events)
• Published language enables code generation

Separate Ways

Separate Ways is the explicit decision to NOT integrate two bounded contexts. The contexts remain completely independent, solving similar problems separately, even if this means duplicating effort.

This might seem wasteful, but separate ways is sometimes the right choice:

When Separate Ways Makes Sense

•Integration Cost Exceeds Value — When the effort to integrate is greater than the benefits. Small, infrequent overlaps aren't worth complex integration.
•Team Autonomy Priority — When organizational structure requires teams to be fully independent. Integration would create unwanted coupling.
•Different Lifecycles — When contexts evolve at drastically different paces and integration would slow the faster one.
•Legacy Replacement — When you're building a new context to eventually replace an old one. Integration with the legacy would delay replacement.
•Experimentation — When one context is experimental and might be discarded. Don't integrate until the experiment succeeds.

Duplication is Not Free

Separate ways means accepting duplication. The same business concept is modeled and maintained in multiple places. This is acceptable when integration cost exceeds duplication cost, but recognize that parallel implementations can drift and create inconsistencies.

Summary: The Context Mapping Vocabulary

We've covered the complete vocabulary for describing relationships between bounded contexts. Here's a concise reference:

Context Relationship Patterns Summary
Pattern	Power Dynamic	Translation	Coordination
Partnership	Equal	Shared	High
Shared Kernel	Equal	None (shared code)	High
Customer-Supplier	Negotiated	Varied	Medium
Conformist	Upstream dominates	None (adopt)	Low
Anti-Corruption Layer	Downstream protects	Full translation	Low
Open Host Service	Upstream serves all	Published	Low
Separate Ways	None	None	None

Key Takeaways

•Context maps visualize relationships — They document how bounded contexts interact, who depends on whom, and what integration patterns are used.
•Partnership requires equal investment — Both teams coordinate closely; high overhead but strong alignment.
•Shared kernel is minimalist — Share only what's absolutely necessary; larger kernels become distributed monoliths.
•Customer-supplier involves negotiation — Downstream can influence upstream; healthier than conformist.
•Conformist accepts foreign models — Pragmatic for non-core domains; risky for core domains.
•ACL protects domain integrity — Essential for core domains integrating with legacy or external systems.
•OHS + PL enable scalable integration — Publish once, consume many; the foundation for platform thinking.
•Separate ways is a valid choice — Not all contexts need to integrate; sometimes independence is worth duplication.

What's Next:

With context mapping patterns understood, we need to explore how contexts actually communicate data and coordinate activities. The next page covers Integration Between Contexts—the technical patterns for implementing the relationships we've discussed.

Page Complete

You now have a complete vocabulary for describing bounded context relationships. Next, we'll dive into the practical implementation patterns for making these relationships work in production systems.