Rules of Thumb - Domain-Driven Design Distilled

Key Principle

Collected heuristics from across the book — actionable guidelines for DDD practitioners.

Always establish Bounded Contexts and Ubiquitous Language before modeling Aggregates (Chapter 1)
One team per Bounded Context, one repository per Bounded Context (Chapter 2)
Develop language through concrete scenarios, not noun lists (Chapter 2)
If a concept doesn't belong in the Ubiquitous Language, it doesn't belong in the model (Chapter 2)
The code is the model — ceremony is for weddings, not domain models (Chapter 2)
Core Domains get the best developers; Generic Subdomains get purchased solutions (Chapter 3)
If you're building something you could buy, question whether it's truly Core (Chapter 3)
Use Subdomain boundaries on legacy systems to plan incremental extraction (Chapter 3)

Prefer messaging over RPC/REST to eliminate temporal coupling (Chapter 4)
Use Anticorruption Layers when upstream models would pollute your language (Chapter 4)
Design REST resources around consumer use cases, not your internal Aggregates (Chapter 4)
Consume events by schema (JSON, Protobuf), never by importing the publisher's types (Chapter 4)
Timebox Partnership relationships and reassess regularly (Chapter 4)
At-Least-Once Delivery + Idempotent Receiver = reliable messaging (Chapter 4)

Start with single-Entity Aggregates; grow only when a business invariant demands it (Chapter 5)
If two Entities don't share an invariant, they belong in separate Aggregates (Chapter 5)
Hold IDs to other Aggregates, never object references (Chapter 5)
Default to eventual consistency; justify immediate consistency with a specific invariant (Chapter 5)
Ask Domain Experts about time tolerances, not developers about database transactions (Chapter 5)
Use exaggerated time frames ("could it wait a week?") to surface real business thresholds (Chapter 5)
Paper-system thinking reveals that most business processes already tolerate delay (Chapter 5)
Embed business logic in domain objects, not in Application Services (Chapter 5)

Name events as past-tense verbs: ProductCreated, BacklogItemCommitted (Chapter 6)
Include command-derived properties, not entire Aggregate state (Chapter 6)
Always persist the Aggregate and its Domain Events atomically (Chapter 6)
Enforce causal ordering at the consumer, not just the producer (Chapter 6)
Avoid generically named events (BacklogItemUpdated) — be specific about what happened (Chapter 6)
Event Sourcing requires CQRS in practice (Chapter 6)

Treat modeling as delivery work, not overhead competing with delivery (Chapter 7)
Sequence discovery as: Events → Commands → Aggregates → Boundaries (Chapter 7)
Timebox modeling sessions but track modeling debt explicitly (Chapter 7)
Knowledge acquisition is continuous — never label a Core Domain as "maintenance phase" (Chapter 2)
If design discussions center on database tables, you're doing data modeling, not domain modeling (Chapter 1)

The Core Framework: Strategic Before Tactical - The thesis these heuristics support
Implementation Playbook - Sequencing these heuristics into practice