Domain Expert Developer
Monolithic Data Models (Big
Ball of Mud)
Anemic Data Models
Relational-Database way of
Smaller Independent Domain
Models / Integration
Rich Behavior Objects (OOP
What is DDD?
It is an Approach to develop software for
- Complex needs
- Evolving models
It is Not a technology or a methodology
It is a Way of Thinking
Brief History of DDD
Eric Evans – 2003
DDD Community (http:// www.domaindrivendesign.org)
Jimmy Nilson – 2006
Greg Young – 2008 / 2013
Vaughn Vernon – 2013
P:PubTechnical_documentationDomain Driven Design (DDD)
The Business Value of DDD
1. The organization gains a useful model of its domain.
2. A refined, precise definition and understanding of the business is developed.
3. Domain experts contribute to software design.
4. A better user experience is gained.
5. Clean boundaries are placed around pure models.
6. Enterprise architecture is better organized.
7. Agile, iterative, continuous modeling is used.
8. New tools, both strategic and tactical, are employed.
Domain (Problem Space)
A sphere of knowledge, influence, or activity (or “The Business”)
Domain Model (Solution Space)
A system of abstractions that:
•Describes selected aspects of a domain and
•Can be used to solve problems related to that domain.
Problem Space vs Solution Space
Domain Domain Model
The setting in which a word or statement appears that
determines its meaning.
A description of a boundary (typically a subsystem, or the work of
a particular team) within which a particular model is defined and
Translation Map between Bounded Contexts.
A language structured around the domain model.
Used by all team members, within a bounded context, to connect
all the activities of the team with the software.
Ubiquitous Language - An Example
Requirements for “Customer”
•Change Personal Name
•Set Postal Address
•Relocate to Postal Address
•Change Home Telephone
•Disconnect Home Telephone
•Set Primary Email Address
•Set Secondary Email Address
•In certain cases, one Model cannot make it
•Multiple Models – Integration with Strategic Design
•Ubiquitous Language in Model, Code, Spoken & Written Language
•Be a Good Listener – Understand the Problem Space
•The “worst” Domain Expert is the Best in the World compared to us
•The obvious is not adequate. Focus on Exceptions
•How would / does the Domain function Without Computers?
•Initial Analysis and Design are Not Dogmas – Knowledge comes Slowly
•Model-Driven Design as OOP done right
•Focus on What instead of How
•Focus on Behavior (hidden in Verbs) instead of Data (hidden in Nouns)
•Be familiar with, Design Patterns and Principles
•Command Query Responsibility Segregation
•Event – Driven Architecture
•Hexagonal Architecture / Ports & Adapters
Strategic, Tactical, DDD, OOP, CQRS, UI, ES, EDA, ….
For the things we have to learn before we can do them,
we learn by doing them.