Domain-Driven Design: Strategic Design

DDD (Eric Evans) centers software design around a deep, explicitly modeled understanding of the business domain, built through ongoing collaboration between developers and domain experts. Strategic Design handles the big-picture concerns; Tactical Design (next page) provides the implementation building blocks.

Ubiquitous Language

• A shared vocabulary used consistently by domain experts AND developers -- in conversations, docs, AND the code itself (class/method names).

• Eliminates the translation gap: if the business says 'policy lapses', the code should have a lapse() method, not InsuranceStatusInactive.

• Anemic domain model anti-pattern: Entities as plain data bags, all logic in separate services -- DDD pushes the opposite, putting business-rule-enforcing behavior directly on Entities/Aggregates.

Bounded Contexts

// The SAME term can mean different things in different contexts --
// DDD treats this as expected, not a modeling failure to fix.

Sales Context:          Support Context:
  Customer {               Customer {
    paymentMethod           ticketHistory
    creditLimit              satisfactionScore
    billingAddress           preferredContactMethod
  }                       }

// Trying to force ONE shared "Customer" model across both usually
// fits neither well -- each Bounded Context gets its own model,
// even for the "same" real-world concept.

Context Mapping & Anticorruption Layer

• Context Map: documents how Bounded Contexts relate/integrate -- Shared Kernel (small shared model), Customer/Supplier (one depends on and influences another's design), etc.

• Anticorruption Layer (ACL): a translation layer at the boundary with a legacy/external system -- your clean domain model never directly works with the external system's awkward structure.

• Core Domain (competitive differentiator, most modeling investment) vs. Supporting Subdomain (necessary, less investment) vs. Generic Subdomain (solved problem like auth -- buy, don't build).

Event Storming & DDD vs Microservices

• Event Storming: a collaborative workshop mapping a business process as a sequence of Domain Events (past tense) -- surfaces Bounded Context boundaries and builds shared understanding.

• DDD is architecture-agnostic and predates microservices -- Bounded Contexts inform good service boundaries WHEN a team chooses microservices, but a well-modularized monolith organized around Bounded Contexts is a legitimate DDD application too.