Domain-Driven Design

Domain-Driven Design

Overview

Domain-Driven Design standard for robust business software. Enforces separation between domain logic (Entities, Value Objects, Aggregates, Domain Events) and infrastructure frameworks, preventing leaky abstractions.

When to Use

Activate when designing core business domain models, transactional consistency boundaries, enterprise APIs, or complex aggregate hierarchies.

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.