Domain-Driven Design
Domain-Driven Design (DDD) is an approach to building software for complex businesses by modeling code around the same concepts, rules, and vocabulary that domain experts use. It gives teams a shared language and clear boundaries so a large system does not collapse into one tangled model where the same word means different things in different places.
itSoftware engineering | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Domain-Driven Design
Domain-Driven Design centers development on programming a domain model that has a rich understanding of the processes and rules of a business domain. Eric Evans introduced the term and the conceptual framework in his 2003 book. The premise is direct: in most complex applications, the hard problem is not the technology. It is the domain itself — the activity or business the software serves.
DDD responds to that premise with three commitments. You put the core domain and its logic first. You base every design decision on a shared model of that domain. You treat modeling as an ongoing, creative collaboration between developers and domain experts, not a one-time diagram handed to engineering.
Ubiquitous Language: one vocabulary, enforced in code
A Ubiquitous Language is a shared vocabulary that developers and domain experts build together, grounded in the domain model. It has to be precise, because software tolerates no ambiguity the way conversation does.
Use this language everywhere: in code, in conversations with domain experts, in documentation, in tests. When a domain expert uses a term you have not modeled, or objects to a term your code uses, that is signal. Evans frames it as a two-way obligation — domain experts should object to terms that are awkward or inadequate, and developers should watch for ambiguity or inconsistency that will trip up the design. The language evolves as your understanding of the domain deepens.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://martinfowler.com/bliki/DomainDrivenDesign.html
Supports
- Definition of Domain-Driven Design as centering development on a rich domain model
- Origin of the term in Eric Evans's 2003 book
- The Evans classification of entities, value objects, and service objects
- Aggregates as a pattern Evans identified to fill a gap in object-oriented thinking
- Bounded contexts as strategic design and their applicability beyond object-oriented code
- https://martinfowler.com/bliki/BoundedContext.html
Supports
- Bounded Context as the pattern dividing a large domain model into smaller, self-contained units
- Infeasibility of total unification of a domain model for a large system
- Coexistence of multiple models across contexts with explicit translation between them
- https://martinfowler.com/bliki/UbiquitousLanguage.html
Supports
- Ubiquitous Language as a shared vocabulary built by developers and domain experts
- Requirement for precision, since software does not tolerate ambiguity
- Two-way obligation between domain experts and developers to flag awkward or ambiguous terms
- The language evolving as domain understanding deepens
- https://martinfowler.com/bliki/AnemicDomainModel.html
Supports
- Definition of the Anemic Domain Model anti-pattern
- Domain objects with relationships but no behavior, logic held in separate service objects
- The anti-pattern paying the costs of a domain model without its benefits
- Evans's point that a thin service layer should coordinate while the domain layer holds business rules
- https://www.dddcommunity.org/learning-ddd/what_is_ddd/
Supports
- Definition of DDD as connecting implementation to an evolving model of core business concepts
- Framing of domain complexity, not technology, as the central challenge
- The three foundational DDD practices — core domain focus, model-based design, and expert collaboration
- https://learn.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
Supports
- Strategic vs. tactical DDD phases
- Domain analysis and event storming as ways to build a shared domain understanding
- Core, supporting, and generic subdomain classification with the drone delivery example
- Bounded contexts as the boundary for a specific domain model within a domain
- Context map relationship patterns — Customer-Supplier, Open Host Service, Published Language, Anti-Corruption Layer, Separate Ways
- Conway's Law and aligning team ownership to bounded contexts
- Ubiquitous Language scoped per bounded context, illustrated with the "account" example
- https://learn.microsoft.com/en-us/azure/architecture/microservices/model/tactical-domain-driven-design
Supports
- Entity definition, identity persistence, and the requirement to encapsulate behavior
- Value object definition, immutability, and default-choice guidance over entities
- Aggregate definition, aggregate root, small-aggregate design rule, and identity-only references between aggregates
- Domain service vs. application service distinction
- Domain event definition and internal vs. integration event distinction, illustrated with the drone delivery DeliveryCompleted event
- Anemic domain model as a named antipattern within tactical DDD guidance
- https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer
Supports
- Anti-Corruption Layer pattern originating in Eric Evans's Domain-Driven Design book
- Use case of isolating a modern system from a legacy system's outdated schema or API
- Guidance to keep the layer limited to translation rather than business rules
- https://github.com/heynickc/awesome-ddd
Supports
- Curated list membership and one-line descriptions for the awesome-links entries
- DDD Sample as a joint effort of Domain Language (Eric Evans's company) and Citerus
- Domain Language eLearning as video lessons taught by Eric Evans
- https://github.com/citerus/dddsample-core
Supports
- DDD Sample as the original reference DDD application, moved from SourceForge to GitHub
- Cargo shipping as the modeled business domain
- Joint authorship by Eric Evans's company Domain Language and Citerus
- https://www.eventstorming.com
Supports
- EventStorming as a workshop format for exploring complex business domains across silos
- Alberto Brandolini as its creator
- EventStorming's stated connection to Domain-Driven Design and microservice boundary design
- https://github.com/ddd-crew/context-mapping
Supports
- Context Mapping Cheatsheet covering nine context-map relationship patterns
- Miro-based starter kit for running context-mapping sessions
- https://virtualddd.com
Supports
- Virtual DDD as a community-driven platform for systems and software design knowledge sharing
- Community activities including sessions, book club, and open-space events
- https://virtualddd.com/ddd-heuristics
Supports
- DDD Heuristics as a library of design, guiding, and value-based heuristics
- Heuristics framed as fallible aids rather than guaranteed rules
- https://dddeurope.com
Supports
- Domain-Driven Design Europe as a leading DDD conference with an associated Academy and video archive