Modeling the domain
Domain-Driven Design
Most bugs are translation errors between how the business talks and how the code is written. DDD closes that gap: a ubiquitous language inside explicit bounded contexts, and tactical building blocks — aggregates, value objects, domain events — that put the business rules in the model.
Mark a topic “learned” on its page and watch the bars fill.
Skill map
Learned nodes light up — the glowing one is your next step. Click any node to jump in.
Strategic Design
Modeling the problem space — ubiquitous language, bounded contexts, subdomains, and context maps that describe how teams and models relate.
Decompose what a company does into core, supporting, and generic subdomains — the analysis that drives every later design decision.
✦ Complete · ⏱ 5 min 2 · Beginner Ubiquitous LanguageCultivate one shared, consistent language for the business domain — DDD's cornerstone practice and its single biggest predictor of success.
✦ Complete · ⏱ 3 min 3 · Intermediate Bounded ContextsDivide the ubiquitous language into smaller, internally consistent models — each its own model, physical, and ownership boundary.
✦ Complete · ⏱ 4 min 4 · Intermediate Context Mapping and Integration PatternsThe six patterns for integrating bounded contexts — partnership, shared kernel, conformist, ACL, OHS, separate ways — and the map that charts them.
✦ Complete · ⏱ 4 minTactical Design
Modeling the solution — value objects, entities, aggregates, domain events, and the architectural patterns (event sourcing, CQRS) that implement them.
Immutable types identified by the composition of their values — data plus behavior that cure primitive obsession.
✦ Complete · ⏱ 4 min 6 · Intermediate Entities and AggregatesEntities have identity; aggregates are the consistency and transactional boundary mutated only through their root and committed atomically.
✦ Complete · ⏱ 4 min 7 · Intermediate Domain Events and Domain ServicesPast-tense messages that announce what happened, and stateless objects that host logic spanning multiple aggregates.
✦ Complete · ⏱ 4 min 8 · Advanced Event SourcingPersist an aggregate as an append-only stream of domain events — the source of truth — from which any number of state projections are built.
✦ Complete · ⏱ 4 min 9 · Advanced CQRSCommand-Query Responsibility Segregation — one strongly-consistent command model and any number of read-only projections.
✦ Complete · ⏱ 4 minApplying DDD
Making it real — distilling the core domain, choosing the right modeling heuristic, EventStorming, and evolving a design as the business changes.
The four business-logic patterns (transaction script, active record, domain model, event-sourced) and the architectures that fit them (layered, ports & adapters, CQRS).
✦ Complete · ⏱ 4 min 11 · Advanced Design Heuristics and Evolving DesignAnswer DDD's perennial 'it depends' with a decision tree driven by subdomain type — then evolve those decisions as the business changes.
✦ Complete · ⏱ 4 min 12 · Intermediate EventStormingA low-tech collaborative workshop that models a business process as a timeline of domain events — building shared knowledge and a ubiquitous language fast.
✦ Complete · ⏱ 4 min🗺️ Spend your modeling effort on the core domain
Not every part of a system deserves deep modeling. Find the core domain — the part that gives competitive advantage — and lavish DDD’s tactical patterns there. For generic and supporting subdomains, buy or build something simple. The art of DDD is knowing where the complexity is worth it.