Short Domain Driven Design and UML Refresher

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. The problem
‣ We need to write an application that solves
buissiness problems
Thursday, March 1, 2012

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

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

9. The problem
‣ 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
Thursday, March 1, 2012

10. The problem
‣ 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
Thursday, March 1, 2012

11. The problem
‣ 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
Thursday, March 1, 2012

12. Thursday, March 1, 2012

13. Domain Model ?
Thursday, March 1, 2012

14. Domain Model ?
Thursday, March 1, 2012

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

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

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

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

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

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

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

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

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

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

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

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

27. Thursday, March 1, 2012

28. UML
Thursday, March 1, 2012

29. UML
•UML is perfect to describe, scetch or discuss a domain
model.
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. UML - Class Diagram
‣ class diagram describes the attributes and operations of
a class and also the constraints imposed on the system.
Thursday, March 1, 2012

32. UML - Class Diagram
‣ 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)
Thursday, March 1, 2012

33. UML - Class Diagram
‣ 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“)
Thursday, March 1, 2012

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

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

36. UML - Sequence Diagram
‣ 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
Thursday, March 1, 2012

37. Thursday, March 1, 2012

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

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

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

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

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

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

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

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

54. DDD - Building Blocks
Entities Repository
Values Factory
Services
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. Supple Design „Speak in Domain Language“
‣ Try to explain scenarios loud with the use of the model
and the ubiquitous language
Thursday, March 1, 2012

94. Supple Design „Speak in Domain Language“
‣ 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.
Thursday, March 1, 2012

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

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

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

98. Supple Design „Reduce Associations“
‣ 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?)
Thursday, March 1, 2012

99. Supple Design „Reduce Associations“
‣ 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.
Thursday, March 1, 2012

100. Supple Design „Reduce Associations“
‣ 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
Thursday, March 1, 2012

101. Supple Design „Reduce Associations“
‣ 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
Thursday, March 1, 2012

102. Supple Design „Reduce Associations“
‣ 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 ...
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
Customer Contract Basket Order
OrderItems
Product
AbstractProduct
Prepaid
Thursday, March 1, 2012

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

117. Supple Design - Modules
Customer Order
Customer Contract Basket Order
OrderItems
Product
AbstractProduct
• group by meaning in the domain
• loose coupling between modules
Prepaid
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