1. DDD
Domain Driven Design - The way back to OO!
Felipe Rodrigues de Almeida
DDD blog.fratech.net 1

2. ToPiCS
The Problem
Where are we missing the way? 3
The CoNCePT
What is DDD about? 4
Why use DDD? 6
Where are we missing the way? (Fixes) 8
Layered Architecture 14
The way baCk
Domain Objects 19
Entities, Services, Value Objects and Modules 21
Objects Life-Cycle 26
The meaNiNg
Meaning What? 30
Ubiquitous Language 31
Supple Design 32
Strategic Design 34
DDD blog.fratech.net 2

3. The Problem
where are we missing the way?
• What is important? What is urgent?
• Domain Models vs Manager Models (MOP)
• Bad Communication
• Architects thinking only about infra-structure
• We have lost real Object Orientation
DDD blog.fratech.net 3

4. The CoNCePT
what is DDD about?
Domain means “a sphere of knowledge, influency and activity “
of a situation
So, Domain Driven Design means, design (a software) driven
(oriented) by it knowledge, influency and activity
DDD blog.fratech.net 4

5. The CoNCePT
what is DDD about?
Above all, DDD is about to take the domain (a sphere of
knowledge, influency and activity) and represent it in objects
DDD is the way back to OO!!!
DDD blog.fratech.net 5

6. The CoNCePT
why to use DDD?
More than just a concept, DDD is a process to find out how to
build a system and also to define how to treat specific business
issues
DDD blog.fratech.net 6

7. The CoNCePT
why to use DDD?
Using DDD as a process you will be able to:
• really use all those things your teacher said you could when you
were learning OO
• avoid the Manager(Service) Model (MOP), which requires knowledge
about a specific implementation This kind o design is composed
only by services
• improve the comunication between your team and the customer
DDD blog.fratech.net 7

8. The CoNCePT
where are we missing the way? (Fixes)
• What is important? What is urgent?
The business is important and the customer too Let`s give some
attention to business and customer comunication!
Important aspects cannot be left behind.
DDD blog.fratech.net 8

9. The CoNCePT
where are we missing the way? (Fixes)
• Domain Models vs Manager Models(services) MOP
Domain Models treat the business like objects, services and
compositions, concerned about the way things are connected
in the real world
Developing software is not about creating makers.
DDD blog.fratech.net 9

10. The CoNCePT
where are we missing the way? (Fixes)
• Bad Comunication
The words you use when you are trying to explain a situation to
your customer, who doesn’t know the system, are responsible
for misunderstanding Talking with him using his business terms,
will make for better communication
Use the customers words to communicate!
DDD blog.fratech.net 10

11. The CoNCePT
where are we missing the way? (Fixes)
• Architects thinking only about infra-structure
Architects are “freak“ people that usually think about technical
stuff and forget what is important to the customer
We have to think about business too.
Using DDD design will focus on business situations The internal
transfer of knowledge is easier since communication will be
improved as well
DDD blog.fratech.net 11

12. The CoNCePT
where are we missing the way? (Fixes)
• We have lost real Object Orientation
Object orientation is about the use of objects and their
interactions to design software
At design time, we have to find objects from the real world,
to use for the specific case.
Each domain model is singular and is not applicable to
another model.
DDD blog.fratech.net 12

13. The meaNiNg
wait a minute!
You said: “Each domain model is singular and is not applicable to
another model.”
If I am in an enterprise, why should I have more than 1 model to
describe a single “thing”, perhaps even more that 1 model per
application As a proponent of DRY, this doesn’t make sense to
me
DDD blog.fratech.net 13

14. The CoNCePT
layered architecture
A layered architecture at heart, is a way to separate concerns
Domain model depends on some infrastructure, but not
on a specific impementation.
DDD blog.fratech.net 14

15. The CoNCePT
Presentation layer
Responsible for interacting with the user, getting information
from the user and showing information to the user
The presentation layer usually depends on the application
layer or Data Source Layer!
DDD blog.fratech.net 15

16. The CoNCePT
application layer
Works as delivery, coordinating tasks which the system is
responsible for doing This layer has no business rules and is only
responsible for delegating work to domain objects Its objects
do not have state to reflect business situation, but can have
state of a task’ s progress
Consists of a set of decorators, delegating calls to domain
layer.
DDD blog.fratech.net 16

17. The CoNCePT
Data Source layer
A set of generic technical capabilities, providing support for
higher layers
Here goes the most technical things!
DDD blog.fratech.net 17

18. The CoNCePT
Domain layer
Represents the concepts of business information and business
situation
A set of generic technical capabilities, providing support for
higher layers
This layer is the heart of business software!
DDD blog.fratech.net 18

19. The way baCk
Domain objects
Domain Objects are instances of real entities which hold any
knowledgenemt, influency or activity of a situation
We can figure out which domain objects we need, by talking to
domain experts
Focusing on key words will help to define domain objects.
DDD blog.fratech.net 19

20. The way baCk
Domain objects
DDD blog.fratech.net 20

21. The way baCk
entities
Any object which has an identity Usually is mapped to real world
objects
Unique set of data.
DDD blog.fratech.net 21

22. The way baCk
Value objects
Used to describe characteristic of things It is part of the domain
as much as entities, but is always under some model element,
since it has no identity
Set of data without identity.
DDD blog.fratech.net 22

23. The way baCk
Services
Services are a standalone interface, which holds operations that
don’t fit in any object in the model
It is not a thing, but a set of operations.
DDD blog.fratech.net 23

24. The meaNiNg
wait a minute!
You’ve said earlier that DDD is better than service/manager
models, but here you’re saying that DDD uses services Make
sure that you describe how this type of service is different from
the other
DDD blog.fratech.net 24

25. The way baCk
modules
Organize your domain objects by modules, then whenever you
need anything you know where it is
Don’t drive your modules by infrastrucure.
DDD blog.fratech.net 25

26. The way baCk
objects life Cycle
Once you have decided the main objects of your system, you
then know about its life cyle How will it interact in the model?
Who is able to use it?
Aggregate, Factory and Repository patterns stand for objects
life cycle
The point is avoid showing internal complexity to the
client.
DDD blog.fratech.net 26

27. The way baCk
aggregates
A set of objects with a unique interface for external calls Indicated
for cases where you need keep consistent a set of objects
Aggregates always have a root responsible for being the
interface for others elements.
DDD blog.fratech.net 27

28. The way baCk
Factories
Responsible for creation of domain objects or even an entire
aggregate
Required only when creation becomes too complicated.
DDD blog.fratech.net 28

29. The way baCk
repositories
Works as a “repository“ for domain objects Provides a simple
interface for complex persistence operations Can encapsulate
several data sources for a object
Make a repository whenever you find a type that needs
global access.
DDD blog.fratech.net 29

30. The meaNiNg
meaning what?
All software has a meaning Modeling is about find the meaning
of software
Find the meaning, express it and you will have a great
model.
DDD blog.fratech.net 30

31. The meaNiNg
Ubiquitous language
Created by the team, maintained by the team and for the team
Ubiquitous Language has to be concerned about the business
in question
Works like a dictionary, composed by the terms taken
from Domain Experts.
DDD blog.fratech.net 31

32. The meaNiNg
Supple Design
Created by the team, mainteined by the team and for the team
Have to concern about the business in question
A set of concepts to make a flexible design.
DDD blog.fratech.net 32

33. The meaNiNg
Supple Design - Some Patterns
x Intention-Revealing Interfaces
x Standalone Classes
x Conceptual Contours
DDD blog.fratech.net 33

34. The meaNiNg
Strategic Design
A set of good pratices to achieve a good Domain Model
These patterns can works as a check list to improve the design
quality
If you want you can express these patterns as documents.
DDD blog.fratech.net 34

35. The meaNiNg
Strategic Design
DDD blog.fratech.net 35

36. The meaNiNg
Strategic Design
DDD blog.fratech.net 36

37. The meaNiNg
Strategic Design
DDD blog.fratech.net 37

38. The meaNiNg
Strategic Design
DDD blog.fratech.net 38

39. The meaNiNg
Strategic Design
DDD blog.fratech.net 39

40. The meaNiNg
Strategic Design
DDD blog.fratech.net 40

41. The meaNiNg
Strategic Design
DDD blog.fratech.net 41

42. The meaNiNg
Strategic Design
DDD blog.fratech.net 42

43. The meaNiNg
wait a minute!
Have you considered making a connection between “Published
Language” and DSLs? I forgot about this aspect, but using DDD
is a fantastic way to have an architecture that can transform into
a DSL via this route
DDD blog.fratech.net 43

44. The meaNiNg
Strategic Design
DDD blog.fratech.net 44

45. waiT a miNUTe!
* The “Wait a minute!” questions are real questions from Ian
Roughley after review this document. Thank you Ian!
** No, that man is not Ian.
DDD blog.fratech.net 45

46. The eND
obrigado!
Felipe Rodrigues de Almeida
felipe@fratech net
blog fratech net
DDD blog.fratech.net 46