This document discusses Domain Driven Design (DDD). It provides an overview of DDD, including that it focuses on removing translation barriers between a domain, development team, and software design. It also describes common building blocks of domain models such as entities, value objects, factories, repositories, and services. Additionally, it discusses refactoring a model to gain deeper insight, including making implicit concepts explicit.
Unleashing Real-time Insights with ClickHouse_ Navigating the Landscape in 20...
Domain Modeling Fundamentals in DDD
1. Up to Speed in
Domain Driven Design
Rick van der Arend
rvdarend@sogyo.nl
2. Agenda
What is Domain Driven Design?
An example of a domain model
The building blocks of a domain model
Refactoring towards deeper insight
What has been learned since the book?
Wrap-up
SOFTWARE INNOVATORS 2
4. DDD in one sentence
Domain Driven Design is a style of software
development which focuses on removing translation
barriers between domain, development team and
design of working software using a ubiquitous
language supported by a well refined livingmodel.
5. Translation barriers
Team talks to users and experts (if lucky)
Write software that behaves as requested
Names get translated back and forth
Concepts diverge without anyone noticing
SOFTWARE INNOVATORS 5
?
7. Origins of the acronym DDD
Eric Evans wrote the book that gave the
acronym DDD an impulse in 2005. Aptly named:
Domain Driven Design
“Tackling Complexity in the heart of software”
9. Domain model
SOFTWARE INNOVATORS 9
Parallel to the equator
Parallel to the earth axis
Orthogonal to the sun’s plain of movement Turning during the year
10. From Phased to Iterations
Analysis Design Build
Iteration Iteration
Test
11. Start with the Model, don’t stop
SOFTWARE INNOVATORS 11
Iteration Iteration
Domain Model
effort as part
of an iteration
14. Entities & Value objects
Entities have an unmistakeable identity
Value objects are indentified by.. their value
a Person
a Name
an Address
This depends on.. of course.. Context!
15. Factories , Repositories, Aggregates
Factories create, Repositories store
The unit of work they work on is an aggregate
The thing they create of find and hand over will
be a reference to the aggregate root
16. Services
Services encapsulate... well… Services
They are not part of the core domain, but linked
Objects change into other objects
17. Layers.. and more
UI > domain model > Data access
SOFTWARE INNOVATORS 17
Or.. domain model depends on nothing
19. Refactoring towards deeper insight
Use patterns when appropriate
Make Unit Tests
Better yet, do TDD
Better yet, do BDD
DRY and YAGNI
But: all a bit technical
20. Making Implicit Concepts explicit
Listen to Language
Scrutinize Awkwardness
Contemplate Contradictions
Read the Book
Try, Try again
Model the less-than-obvious: constraints,
processes, commands, relations, etc.
23. Strategic Design: context rules!
Be aware of different contexts
Make a context map
See how different bounded contexts relate
Shared Kernel, Customer/Supplier development
teams, Conformist, Separate Ways, Partner
Use an anti-corruption layer
24. Context Maps step-by-step
1. What models (or BBoM) do we know of? (draw
blob each and name it.)
2. Where does each apply? (Boundary in words.)
3. Where is information exchanged? (Connect)
4. What is the relationship?
(Upstream/downstream? Partner? Etc.)
26. Highlights that Evans learned
Building blocks are overemphasized
But domain events added as a new type of block
General advice
▫ Don’t spread modeling too thin
▫ Focus on the core domain
▫ Clean, bounded context (CM steps available)
▫ Iterative process
▫ Don’t bore your domain experts
27. Domain events taken further
Greg Young has been promoting the idea of
Command and Query separation
28. Techniques to explore
Exploratory Modeling (xM)
Model Driven Development environments
Language Workbenches
Naked Objects and other such platforms
SOFTWARE INNOVATORS 28
30. Summary
DDD highlights aspects of software design
It focuses on the ‘core domain’ and uses a
ubiquitous language, based on a domain model
The ubiquitous language brings out flaws
A Domain Model is normally made up of certain
types of building blocks
Thinks about context too: take control where and
whenever possible
31. Resources for Further study
http://www.domaindrivendesign.org
Numerous articles on http://www.infoq.com
http://www.slideshare.net/devnology/unleash-
your-domain-with-greg-young
32. DDD in C#
Jimmy Nilsson applied it to a C# context. His
book is has an informal tone, but a bit noisy.
Applying DDD and Patterns
With Examples in C# and .NET