Domain-Driven Design learning path: everything to study, topic by topic

The shared, precise vocabulary developed collaboratively between domain experts and developers that is used consistently in code, documentation, and conversation. Covers how to discover, build, and evolve a ubiquitous language within a bounded context.

The explicit boundary within which a domain model applies and its ubiquitous language is consistent. Covers how the same term can mean different things in different bounded contexts, and how context boundaries map to team and system boundaries.

Partitioning the problem space into core, supporting, and generic subdomains based on business value and competitive differentiation. Covers how subdomain classification drives investment decisions and influences whether to build, buy, or outsource.

Approaching system design from the business problem space before jumping to technical solutions. Covers domain discovery, knowledge crunching with domain experts, and how strategic thinking prevents over-engineering and misaligned models.

A collaborative modelling technique where domain experts narrate how the domain works using pictographic language. Covers pictograms, scenarios, and how domain storytelling helps discover bounded contexts and ubiquitous language.

Techniques for describing the relationships and integrations between bounded contexts. Covers Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language, Big Ball of Mud, and Separate Ways.

A workshop-based discovery technique that uses domain events on a timeline to explore an entire business domain collaboratively. Covers facilitating event storming, identifying bounded contexts, hotspots, and pivotal events at scale.

The upstream-downstream context relationship where the upstream team (supplier) provides a service or model that the downstream team (customer) consumes. Covers power dynamics, negotiation, and protecting downstream teams from upstream volatility.

Context mapping patterns where a bounded context exposes a well-defined protocol (OHS) and a shared formalized language (Published Language) for multiple downstream consumers. Covers API design as OHS, versioning strategies, and schema registries as Published Language.

Identifying and protecting the most strategically important part of the domain — the core domain — from supporting and generic concerns. Covers the distillation document, core domain vision, and how to focus the best engineering talent on core differentiation.

Two fundamental building blocks of the domain model. Entities have identity that persists through state changes; value objects are defined entirely by their attributes and are immutable. Covers identity strategies, value object equality, and when to prefer value objects.

Clusters of domain objects treated as a single unit for data changes. The aggregate root is the sole entry point for modifying the cluster. Covers aggregate boundaries, the one-transaction-per-aggregate rule, and referencing aggregates by identity.

Immutable records of something significant that happened in the domain. Covers naming conventions (past tense, domain language), publishing events from aggregate roots, event handlers, and how domain events enable eventual consistency between aggregates.

Stateless operations that express domain logic that does not naturally belong to any single entity or value object. Covers when to introduce a domain service, naming in ubiquitous language, and how domain services differ from application services.

Abstractions that mediate between the domain model and the data mapping layer. Covers repository interface design in domain terms, aggregate-per-repository convention, the persistence ignorance principle, and avoiding repository bloat.

Domain objects responsible for complex creation logic when constructors are insufficient. Covers factory methods on aggregate roots, standalone factory objects, reconstitution from persistence, and when factories replace constructors.

Heuristics for sizing and structuring aggregates correctly: protect invariants, design small aggregates, reference other aggregates by identity, and update multiple aggregates using eventual consistency. Covers the four rules from Vernon's IDDD.

Designing aggregates so that all business rules (invariants) are always satisfied within the consistency boundary. Covers guard clauses, domain exceptions, the always-valid pattern, and deferred validation trade-offs.

Encapsulating business rules as composable, testable specification objects. Covers the Specification interface, composite specifications (and/or/not), and using specifications for validation, selection, and construction.

The contrast between anemic domain models (data containers with no behavior) and rich domain models (objects with both data and business behavior). Covers why anemia is an anti-pattern, its origins in procedural thinking, and how to refactor toward richness.

Persisting the state of an aggregate as a sequence of domain events rather than the current snapshot. Covers event append-only stores, replaying events to rebuild state, snapshotting for performance, and the audit trail as a first-class capability.

Command Query Responsibility Segregation separates the write model (commands that change state) from the read model (queries that return data). Covers task-based UIs, read model optimisation, and the spectrum from simple to fully distributed CQRS.

The infrastructure for persisting and reading event streams. Covers event store design, stream partitioning, projections that build read models from events, and catch-up subscriptions for rebuilding views.

Managing the window of inconsistency between aggregates that communicate through events. Covers the saga pattern, process managers, compensating transactions, and designing UIs that tolerate temporary inconsistency.

Applying DDD bounded contexts as the primary heuristic for microservice decomposition. Covers aligning service boundaries to context boundaries, avoiding distributed monoliths, team topologies aligned to bounded contexts, and the strangler fig pattern for migration.

Common mistakes when applying DDD: the anaemic model, god aggregates, leaking domain logic into application services, ignoring ubiquitous language, and using DDD for simple CRUD. Covers strategies to detect and refactor each anti-pattern.