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.

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

3. SOFTWARE INNOVATORS 3
What is DDD?
“Putting the Domain Model to work”

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
?

6. Domain, Team and Model
Ubiquitous Language

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”

8. SOFTWARE INNOVATORS 8
An Example of a domain model

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

12. SOFTWARE INNOVATORS 12
The building blocks of a
Model-Driven Design

13. Building blocks of MDD

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

18. SOFTWARE INNOVATORS 18
Refactoring towards deeper
insight

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.

21. SOFTWARE INNOVATORS 21
Strategic Design

22. Contents of chapter 4 as a model

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.)

25. SOFTWARE INNOVATORS 25
What has been learned since
the book?

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

29. SOFTWARE INNOVATORS 29
Quick Wrap-up

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

33. SOFTWARE INNOVATORS 33
Contact
Rick van der Arend
rvdarend@sogyo.nl
030 - 220 22 16
Web: www.sogyo.nl
Blog: www.software–innovators.nl