The document discusses Domain Driven Design (DDD). It provides an overview of some key DDD concepts including the domain model, ubiquitous language, layered architecture, and common building blocks. The domain model offers a simplified view of the problem domain understood by both domain experts and implementers. It can be represented through text, UML diagrams, or code. Key building blocks in DDD include entities, values, services, repositories, and factories. The document also discusses finding a "supple design" that aligns with the problem domain.

1. Thursday, March 1, 2012

2. Domain Driven Design
short Refresher
FLOW3 Usergroup @AOE
by Daniel Pötzinger
Thursday, March 1, 2012

3. Thursday, March 1, 2012

4. The problem that we want to
solve
Thursday, March 1, 2012

5. The problem
Thursday, March 1, 2012

6. ‣ We need to write an application that solves
buissiness problems
The problem
Thursday, March 1, 2012

7. ‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
The problem
Thursday, March 1, 2012

8. ‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
‣ We need to find a good design:
The problem
Thursday, March 1, 2012

9. ‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
‣ We need to find a good design:
‣ understanding the problem and the buissiness
The problem
Thursday, March 1, 2012

10. ‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
‣ We need to find a good design:
‣ understanding the problem and the buissiness
‣ find understandable class-structure
The problem
Thursday, March 1, 2012

11. ‣ We need to write an application that solves
buissiness problems
‣ We want to use OOP
‣ We need to find a good design:
‣ understanding the problem and the buissiness
‣ find understandable class-structure
‣ build maintainable software, that can be adjusted
easy when the buissiness changes
The problem
Thursday, March 1, 2012

12. Thursday, March 1, 2012

13. Domain Model ?
Thursday, March 1, 2012

14. Domain Model ?
Thursday, March 1, 2012

15. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Thursday, March 1, 2012

16. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Domain Experts
Thursday, March 1, 2012

17. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Domain Experts
Implementators
Thursday, March 1, 2012

18. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Domain Experts
Implementators
Thursday, March 1, 2012

19. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Domain Experts
Implementators
Knowledge Crunching
& Analysis
Thursday, March 1, 2012

20. ‣ The domain model offers a simplified, abstract view of
the problem
Domain Model
Domain Model
Domain Experts
Implementators
Knowledge Crunching
& Analysis
Thursday, March 1, 2012

21. ‣ a common language should be used to describe the
problem
Domain Model
Domain Model
Domain Experts
Implementators
Ubiquitous
Domain Language
Uses terms
Both understand
Thursday, March 1, 2012

22. ‣ a common language should be used to describe the
problem
Domain Model
Domain Model
Domain Experts
Implementators
Ubiquitous
Domain Language
Uses terms
Both understand
Thursday, March 1, 2012

23. ‣ The Domain Model can be represented as Text, Speech
or Code...
Domain Model
Domain Model
Thursday, March 1, 2012

24. ‣ The Domain Model can be represented as Text, Speech
or Code...
Domain Model
Domain Model
Text
A customer can have multiple contracts.
The customer gets monthly bills to his
billing address.
Thursday, March 1, 2012

25. ‣ The Domain Model can be represented as Text, Speech
or Code...
Domain Model
Domain Model
Text
UML
A customer can have multiple contracts.
The customer gets monthly bills to his
billing address.
Thursday, March 1, 2012

26. ‣ The Domain Model can be represented as Text, Speech
or Code...
Domain Model
Domain Model
Text
UML
A customer can have multiple contracts.
The customer gets monthly bills to his
billing address.
Code
Thursday, March 1, 2012

27. Thursday, March 1, 2012

28. UML
Thursday, March 1, 2012

29. •UML is perfect to describe, scetch or discuss a domain
model.
UML
UML
Structural Diagrams Behavioral Diagrams
Class Diagrams Object Diagrams Sequence Diagrams Use Case Diagram ......
Thursday, March 1, 2012

30. UML - Class Diagram
Thursday, March 1, 2012

31. ‣ class diagram describes the attributes and operations of
a class and also the constraints imposed on the system.
UML - Class Diagram
Thursday, March 1, 2012

32. ‣ class diagram describes the attributes and operations of
a class and also the constraints imposed on the system.
‣ Can be directly mapped to code (OOP)
UML - Class Diagram
Thursday, March 1, 2012

33. ‣ class diagram describes the attributes and operations of
a class and also the constraints imposed on the system.
‣ Can be directly mapped to code (OOP)
‣ Popular use-case is to explain conceptual important
parts => keep it simple („draw it on a paper“)
UML - Class Diagram
Thursday, March 1, 2012

34. ‣ classes with:
‣ attributes (<name>:<type> )
‣ methods
‣ annotations and properties
‣ Associations
‣ Multiplicity, roles
‣ Traversal
‣ Aggregation, Composition
‣ Inheritance, Dependency
‣ Qualifier
‣ Association Class
UML - Class Diagram - Examples
Thursday, March 1, 2012

35. ‣ Depend on class diagrams
‣ „Snapshot“ of instances and theire relations
‣ Perfect to understand object behaviour and their
relationship from practical perspective
UML - Object Diagram
Thursday, March 1, 2012

36. ‣ Depend on class diagrams
‣ Perfect to explain how objects work together to
„fulfill“ a use-case.
‣ useful to detect weakness and improvements in your
design
UML - Sequence Diagram
Thursday, March 1, 2012

37. Thursday, March 1, 2012

38. Domain Driven Design
Basics
Thursday, March 1, 2012

39. 1. Layered Architecture
2. Common Building Blocks and Rules
3. Find a „supple design“
4. See the big picture
Domain Driven Design - Basics
Thursday, March 1, 2012

40. DDD - Layered Architecture
Thursday, March 1, 2012

41. DDD - Layered Architecture
Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats
Thursday, March 1, 2012

42. DDD - Layered Architecture
Domain Model
Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats
Core Business Logic
Thursday, March 1, 2012

43. DDD - Layered Architecture
Domain Model
Application Layer (thin)
Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)
Thursday, March 1, 2012

44. DDD - Layered Architecture
Domain Model
Application Layer (thin)
Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)User /
Other Apps
Thursday, March 1, 2012

45. DDD - Layered Architecture
Domain Model
Application Layer (thin)
View
Infrastructure / System
Logging
Persitence
Speaking to Webservices
File Formats
Core Business Logic
Controller / (Export/Import)
Templates / Presentation Objects
User /
Other Apps
Thursday, March 1, 2012

46. Thursday, March 1, 2012

47. Building Blocks
Thursday, March 1, 2012

48. Building Blocks
Thursday, March 1, 2012

49. DDD - Building Blocks
Thursday, March 1, 2012

50. DDD - Building Blocks
Entities
Thursday, March 1, 2012

51. DDD - Building Blocks
Entities
Values
Thursday, March 1, 2012

52. DDD - Building Blocks
Entities
Values
Services
Thursday, March 1, 2012

53. DDD - Building Blocks
Entities
Values
Services
Repository
Thursday, March 1, 2012

54. DDD - Building Blocks
Entities
Values
Services
Repository
Factory
Thursday, March 1, 2012

55. DDD - Building Blocks
Thursday, March 1, 2012

56. DDD - Building Blocks
Entities
Thursday, March 1, 2012

57. DDD - Building Blocks
Entities
Object which is primary defined by its identity (not by
attributes). For example "Person", "Car", "Costumer" or
"BankTransaction".
Thursday, March 1, 2012

58. DDD - Building Blocks
Entities
Object which is primary defined by its identity (not by
attributes). For example "Person", "Car", "Costumer" or
"BankTransaction".
• often has some ID value
Thursday, March 1, 2012

59. DDD - Building Blocks
Entities
Object which is primary defined by its identity (not by
attributes). For example "Person", "Car", "Costumer" or
"BankTransaction".
• often has some ID value
• continuity through livecycle
Thursday, March 1, 2012

60. DDD - Building Blocks
Entities
Object which is primary defined by its identity (not by
attributes). For example "Person", "Car", "Costumer" or
"BankTransaction".
• often has some ID value
• continuity through livecycle
• keep class definition simple / focus on live cycle
Thursday, March 1, 2012

61. DDD - Building Blocks
Thursday, March 1, 2012

62. DDD - Building Blocks
Value
Thursday, March 1, 2012

63. DDD - Building Blocks
Value
describe the characteristic of a thing and identity is not
required. (We care what they are - not who) Example:
address, color ...
Thursday, March 1, 2012

64. DDD - Building Blocks
Value
describe the characteristic of a thing and identity is not
required. (We care what they are - not who) Example:
address, color ...
• should represent a whole value (conceptual thing )
Thursday, March 1, 2012

65. DDD - Building Blocks
Value
describe the characteristic of a thing and identity is not
required. (We care what they are - not who) Example:
address, color ...
• should represent a whole value (conceptual thing )
• Often passed as arguments
Thursday, March 1, 2012

66. DDD - Building Blocks
Value
describe the characteristic of a thing and identity is not
required. (We care what they are - not who) Example:
address, color ...
• should represent a whole value (conceptual thing )
• Often passed as arguments
• No Identity gives freedom
Thursday, March 1, 2012

67. DDD - Building Blocks
Value
describe the characteristic of a thing and identity is not
required. (We care what they are - not who) Example:
address, color ...
• should represent a whole value (conceptual thing )
• Often passed as arguments
• No Identity gives freedom
• should be Immutable!
Thursday, March 1, 2012

68. DDD - Building Blocks
Thursday, March 1, 2012

69. DDD - Building Blocks
Service
Thursday, March 1, 2012

70. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
Thursday, March 1, 2012

71. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
• stateless
Thursday, March 1, 2012

72. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
• stateless
• offer a useful service or action and deals with other domain
objects
Thursday, March 1, 2012

73. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
• stateless
• offer a useful service or action and deals with other domain
objects
• defined in common domain language
Thursday, March 1, 2012

74. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
• stateless
• offer a useful service or action and deals with other domain
objects
• defined in common domain language
• do not mix with other layers
Thursday, March 1, 2012

75. DDD - Building Blocks
Service
“...if a single process or transformation in domain is not a
natural responsibility of an entity or value => make it a
standalone service with a nice interface."
• stateless
• offer a useful service or action and deals with other domain
objects
• defined in common domain language
• do not mix with other layers
Examples: FundTransferService / PackageRoutingService / SimCardActivationService
Thursday, March 1, 2012

76. DDD - Building Blocks
Thursday, March 1, 2012

77. DDD - Building Blocks
Repository
Thursday, March 1, 2012

78. DDD - Building Blocks
Repository
For each object where you need global access create a
repository object that can provide the illusion of an in
memory collection of all objects of that type. Setup
access through a well knows global interface.
Thursday, March 1, 2012

79. DDD - Building Blocks
Repository
For each object where you need global access create a
repository object that can provide the illusion of an in
memory collection of all objects of that type. Setup
access through a well knows global interface.
• typicaly methods for add() remove() and find*()
Thursday, March 1, 2012

80. DDD - Building Blocks
Repository
For each object where you need global access create a
repository object that can provide the illusion of an in
memory collection of all objects of that type. Setup
access through a well knows global interface.
• typicaly methods for add() remove() and find*()
•find* methods communicate design decisions about how to
access the data
Thursday, March 1, 2012

81. DDD - Building Blocks
Repository
For each object where you need global access create a
repository object that can provide the illusion of an in
memory collection of all objects of that type. Setup
access through a well knows global interface.
• typicaly methods for add() remove() and find*()
•find* methods communicate design decisions about how to
access the data
• ..reconstitution?
Thursday, March 1, 2012

82. DDD - Building Blocks
Thursday, March 1, 2012

83. DDD - Building Blocks
Factory
Thursday, March 1, 2012

84. DDD - Building Blocks
Factory
A factory hides logic for building objects - this is
especially relevant for aggregates!
Thursday, March 1, 2012

85. DDD - Building Blocks
Factory
A factory hides logic for building objects - this is
especially relevant for aggregates!
• atomic (need to pass all essential parameters)
Thursday, March 1, 2012

86. DDD - Building Blocks
Factory
A factory hides logic for building objects - this is
especially relevant for aggregates!
• atomic (need to pass all essential parameters)
• not allowed to give wrong results (exceptions)
Thursday, March 1, 2012

87. DDD - Building Blocks
Factory
A factory hides logic for building objects - this is
especially relevant for aggregates!
• atomic (need to pass all essential parameters)
• not allowed to give wrong results (exceptions)
• entity vs. value factories
Thursday, March 1, 2012

88. DDD - Building Blocks
Factory
A factory hides logic for building objects - this is
especially relevant for aggregates!
• atomic (need to pass all essential parameters)
• not allowed to give wrong results (exceptions)
• entity vs. value factories
• (can also be used for reconstitution )
Thursday, March 1, 2012

89. Thursday, March 1, 2012

90. Find a Supple Design
Thursday, March 1, 2012

91. Find a Supple Design
vs.
Thursday, March 1, 2012

92. Supple Design „Speak in Domain Language“
Thursday, March 1, 2012

93. ‣ Try to explain scenarios loud with the use of the model
and the ubiquitous language
Supple Design „Speak in Domain Language“
Thursday, March 1, 2012

94. ‣ Try to explain scenarios loud with the use of the model
and the ubiquitous language
‣ Try to explain scenarios more simple/better (find easier
ways to say what you need to say).
=> That helps refining the model.
Supple Design „Speak in Domain Language“
Thursday, March 1, 2012

95. Supple Design „Reduce Associations“
Thursday, March 1, 2012

96. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
Supple Design „Reduce Associations“
Thursday, March 1, 2012

97. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
Supple Design „Reduce Associations“
Thursday, March 1, 2012

98. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
‣ adding qualifier to reduce multiplicity (class missing?)
Supple Design „Reduce Associations“
Thursday, March 1, 2012

99. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
‣ adding qualifier to reduce multiplicity (class missing?)
‣ eliminate non essential assoc.
Supple Design „Reduce Associations“
Thursday, March 1, 2012

100. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
‣ adding qualifier to reduce multiplicity (class missing?)
‣ eliminate non essential assoc.
‣ find and use aggregates
Supple Design „Reduce Associations“
Thursday, March 1, 2012

101. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
‣ adding qualifier to reduce multiplicity (class missing?)
‣ eliminate non essential assoc.
‣ find and use aggregates
=> Intuition and Refactoring
Supple Design „Reduce Associations“
Thursday, March 1, 2012

102. ‣ Avoid many association and use only a minimum of
relations because they decrease maintainability!
‣ traversal instead of bidirectional
‣ adding qualifier to reduce multiplicity (class missing?)
‣ eliminate non essential assoc.
‣ find and use aggregates
=> Intuition and Refactoring
... country / president example ...
Supple Design „Reduce Associations“
Thursday, March 1, 2012

103. Supple Design - Aggregates
Thursday, March 1, 2012

104. Supple Design - Aggregates
‣ An aggregate is a group of objects that belong together
(a group of individual objects that represents a unit)
Thursday, March 1, 2012

105. Supple Design - Aggregates
‣ An aggregate is a group of objects that belong together
(a group of individual objects that represents a unit)
‣ ...car example... (root, boundary, invariants )
Thursday, March 1, 2012

106. Supple Design - „Explicit constrains“
Thursday, March 1, 2012

107. Supple Design - „Explicit constrains“
‣ name and make constrains explicit.That gives it a name
you can talk about and the code is more
understandable
Thursday, March 1, 2012

108. Supple Design - „Explicit constrains“
‣ name and make constrains explicit.That gives it a name
you can talk about and the code is more
understandable
Bucket example
Thursday, March 1, 2012

109. Supple Design - „Specifications“
Thursday, March 1, 2012

110. Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
Thursday, March 1, 2012

111. Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:
Thursday, March 1, 2012

112. Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:
„InventoryDelinquentSpecification“->isSatisfied()
Thursday, March 1, 2012

113. Supple Design - „Specifications“
‣ you can use „Specifications“ to explicit express rules
examples:
„InventoryDelinquentSpecification“->isSatisfied()
„GoldenCustomerSpecification“->isSatisfied($customer)
Thursday, March 1, 2012

114. Supple Design - Modules
If your model tells a story a module is a chapter
Thursday, March 1, 2012

115. Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
Thursday, March 1, 2012

116. Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
• group by meaning in the domain
Thursday, March 1, 2012

117. Supple Design - Modules
Customer Order
Product
Customer Contract Basket Order
OrderItems
AbstractProduct
Prepaid
• group by meaning in the domain
• loose coupling between modules
Thursday, March 1, 2012

118. Supple Design - What else
Thursday, March 1, 2012

119. Supple Design - What else
• Intention Revalving Interfaces
Thursday, March 1, 2012

120. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
Thursday, March 1, 2012

121. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
• closure of operations
Thursday, March 1, 2012

122. Supple Design - What else
• Intention Revalving Interfaces
• standalone classes where possible
• closure of operations
• side effect free functions
Thursday, March 1, 2012

123. Thank you for great year!
Thursday, March 1, 2012

124. Thank you for great year!
Thanks
Thursday, March 1, 2012