Domain-Driven Design

Domain-Driven Design

Overview

A brief summary of what the skill does and its core philosophy.

When to Use

Context for when this skill is applicable.

Rules & Patterns

Domain-Driven Design — Patterns & Practices

When to Use DDD

Use when:

• Complex business logic that goes beyond CRUD
• Multiple domain experts with different vocabularies
• The domain model is the competitive advantage
• Enterprise-grade applications

Don't use when:

• Simple CRUD applications
• Hackathon/MVP (overkill)
• No domain expert available

Strategic Design

Bounded Contexts

The single most important DDD concept. A Bounded Context is a boundary within which a particular model is defined and applicable.

Example — E-Commerce:

[Order Context]          [Payment Context]       [Shipping Context]
  - Order                  - Payment               - Shipment
  - OrderItem              - Transaction            - TrackingNumber
  - Customer (ref)         - Refund                 - Address
  - Address (value)        - Invoice                - Carrier

Customer means different things in each context:

• Order Context: name, email, shipping preference
• Payment Context: billing info, payment methods
• Support Context: ticket history, satisfaction score

Context Map

[Order] ←→ [Payment]     # Partnership
[Order] → [Shipping]     # Customer-Supplier
[Order] → [Legacy CRM]   # Anti-Corruption Layer

Tactical Design

Entities

Objects with identity. Two entities with the same attributes but different IDs are different.

class User {
  readonly id: UserId;
  name: string;
  email: Email;  // Value Object
}

Value Objects

Objects defined by their attributes, not identity. Immutable.

class Email {
  constructor(readonly value: string) {
    if (!isValidEmail(value)) throw new InvalidEmailError(value);
  }
  equals(other: Email): boolean {
    return this.value === other.value;
  }
}