Strategic Design

Introduction

Strategic design in Domain-Driven Design maps business domains to bounded contexts, defines context relationships, and aligns team topology before tactical patterns like aggregates. Uber's marketplace spans ride, eat, freight, and finance — strategic design prevents one "Uber domain model" that nobody can change.

Real production story

Uber Eats engineers reused ride dispatch entities for restaurant delivery timelines — same class names, different business invariants. A "Driver" in rides is supply; a "Courier" in eats has restaurant prep constraints. Shared libraries caused eats releases to break ride ETA calculations. Strategic design workshops produced separate bounded contexts, context maps with published language, and team charters aligned to Conway's Law. Cross-context integration moved to anti-corruption layers and domain events — integration incidents between eats and rides dropped 80% in one year.

Business problem

Uber expands into adjacent businesses faster than one unified model can absorb. Without strategic design, every expansion pollutes core contexts and slows all product lines.

• Product velocity: Eats, rides, and freight need independent evolution — shared model becomes merge bottleneck.
• Language collision: Same word, different meaning — "trip" vs "delivery" vs "load" causes requirement bugs.
• Org alignment: Teams structured around org chart, not domain, build wrong boundaries.

Architecture overview

Strategic design includes subdomain classification (core, supporting, generic), bounded context definition, ubiquitous language per context, and context mapping for integration patterns.

• Core subdomain: Competitive advantage — invest custom model (Uber matching).
• Generic subdomain: Buy or use platform (payments PCI scope).
• Context map: Visual contract between teams — not optional documentation.
• Event storming: Workshop technique to discover boundaries and hot spots.

Architecture motivation

Strategic design answers where to draw boundaries before tactical DDD inside each context. Context maps make integration explicit: partnership, customer-supplier, conformist, anti-corruption layer.

• Force: Multi-product platform with shared infrastructure but distinct business rules.
• Constraint: Cannot rewrite ride core for every new vertical — integrate via defined relationships.
• Outcome: Context map in every major program review; team ownership matches bounded context.

Internal architecture

Uber strategic context map — relationships, not one big model:

• Each arrow labeled with integration pattern and SLA — ACL is not shame, it is design.
• Core contexts get best engineers; generic contexts get vendors or platform teams.

┌─────────────┐     ACL      ┌─────────────┐
│ Ride        │◄────────────►│ Eats        │
│ (core)      │  domain evt  │ (core)      │
└──────┬──────┘              └──────┬──────┘
       │ customer-supplier           │
       ▼                             ▼
┌─────────────┐              ┌─────────────┐
│ Maps/Routing│              │ Restaurant  │
│ (supporting)│              │ (supporting)│
└──────┬──────┘              └─────────────┘
       │ conformist
       ▼
┌─────────────┐
│ Payments    │  (generic — Stripe/partner)
└─────────────┘

Data flow

Cross-context flow uses published language at boundaries — never leak internal entity names across contexts.

• Ride → Payments: TripCompleted event with amount, currency, riderId — not internal Trip aggregate graph.
• Eats → Ride: ACL translates CourierAssigned to logistics vocabulary ride dispatch understands.
• Read models: Each context owns projections; no cross-context SQL joins.

System design diagram

Two diagrams show the Strategic Design topology and the primary request/event path used in production at scale.

Production code example

Context map as code — TypeScript registry Uber platform teams generate from workshops:

• Context map in repo enables CI validation when teams add new consumers.
• Link map entries to ADRs for each ACL implementation.

export const CONTEXT_MAP = {
  ride: {
    type: "core",
    owner: "@uber/ride-platform",
    publishes: ["TripRequested", "TripCompleted", "DriverLocationUpdated"],
    consumes: [],
  },
  eats: {
    type: "core",
    owner: "@uber/eats-platform",
    publishes: ["OrderPlaced", "CourierAssigned", "DeliveryCompleted"],
    consumes: [{ from: "ride", via: "acl", events: ["DriverLocationUpdated"] }],
  },
  payments: {
    type: "generic",
    owner: "@uber/payments-platform",
    publishes: ["ChargeCaptured", "PayoutSettled"],
    consumes: [
      { from: "ride", via: "published_language", events: ["TripCompleted"] },
      { from: "eats", via: "published_language", events: ["DeliveryCompleted"] },
    ],
  },
} as const;

export function assertIntegration(from: string, to: string, pattern: string): void {
  const allowed = CONTEXT_MAP[from as keyof typeof CONTEXT_MAP];
  if (!allowed) throw new Error(`Unknown context: ${from}`);
  // CI fails if new consumer added without map update
}

Enterprise case study

Uber Eats / Rides separation: Shared domain library caused cross-product outages and slow delivery.

• Before: Single shared domain JAR; eats deploy broke ride matching twice per quarter.
• Decision: Event storming, context map, ACL between eats logistics and ride dispatch, separate repos.
• After: Independent deploy cadence; cross-context incidents down 80%; map updated quarterly.

Trade-offs

• Shared kernel vs duplication: Tiny shared IDs/auth only — resist shared domain library.
• Conformist vs ACL: ACL costs dev time; conformist couples you to upstream model changes.
• Big bang vs incremental map: Map current state honestly; evolve one relationship per quarter.
• Central platform vs domain teams: Platform provides infra; domain teams own models.

Security considerations

Context boundaries are security boundaries: PII stays in owning context; events carry minimum necessary fields.

• Data minimization: Cross-context events use IDs and enums — not full user profiles.
• AuthZ per context: Each context validates caller scope — no implicit trust from "internal".
• Audit: Context map documents which systems process regulated data.

Scalability analysis

Strategic design scales organizationally: More products mean more contexts — governance without central bottleneck.

• Context registry: Catalog of contexts, owners, and published events — searchable.
• Onboarding: New vertical adds context to map before writing code.
• Deprecation: Retire contexts with explicit supersede in map — no zombie integrations.

Failure scenarios

Strategic design failures: Big ball of mud context; two teams own same subdomain; ACL skipped "temporarily" for three years.

• Model collision: Shared Trip entity breaks eats — split contexts and ACL.
• Upstream tyranny: Conformist to legacy billing — introduce ACL before next regulatory change.
• Missing map: New team builds direct DB read — block via architecture review and fitness function.

Staff engineer insights

• If your context map hasn't changed in two years, it's probably fiction — domains evolve; update the map or pay in incidents.
• Strategic design is negotiation between product and engineering — the map is the treaty document.
• Generic subdomains are where you stop being clever — buy payments, don't reinvent PCI scope for ego.

Interview questions

Architecture review questions

• Is context map current and linked from program docs?
• Are subdomains classified core/supporting/generic with investment matching?
• Does each context have one owning team and published event catalog?
• Are cross-context integrations labeled ACL/partnership/conformist?
• Was event storming or equivalent done with domain experts?
• Does org chart align with context boundaries or document intentional gaps?

Summary

Strategic design at Uber scale maps multi-product domains to bounded contexts with explicit relationships, subdomain investment strategy, and team alignment — preventing shared model erosion that blocks every product line.