DDD Essentials ESGI Dev Day 2017 Architecture

1. ESSENTIAL DDD
@gboissinot
Dev Day ESGI
2017 February 23

2. SOFTWARE
DESIGN

3. DOMAIN
DRIVEN
DESIGN

5. DDD

6. DDD
IS AN APPROACH

7. DDD
IS AN APPROACH
TO SOFTWARE DESIGN

8. DDD
IS AN APPROACH
TO SOFTWARE DESIGN
FOR COMPLEX
BUSINESS NEEDS

9. THE MOST SIGNIFICANT
COMPLEXITY
OF MANY APPLICATIONS
IS NOT TECHNICAL

10. WE MUST
FOCUS MORE ON
THE BUSINESS CONCERNS

11. “Critical Complexity of most
software projects
is in understanding
the domain itself “
Eric Evans

12. THE DOMAIN
THE PROBLEM
AREA
The reality

13. THE DOMAIN
IS A
SPHERE OF KNOWLEDGE

14. THE DOMAIN
IS A SET OF
CONCEPTS EXPRESSING
DISTILLED KNOWLEDGE

15. THE DOMAIN
IS A SET OF
CONCEPTS EXPRESSING
DISTILLED KNOWLEDGE, RULES,
ASSUMPTIONS, CONCEPTS
ABOUT A BUSINESS MODEL

16. THERE ARE
NO BORING
DOMAINS

17. COMPLEXITY
FROM THE
DOMAIN IS
INHERENT

18. COMPLEXITY
FROM THE
TECHNICAL
IS ACCIDENTAL

19. SOLVING COMPLEX
PROBLEMS BY USING
MODELS

20. A MODEL

21. A MODEL
REPRESENTS
A VIEW

22. A MODEL
DESCRIBES THE
OUTSIDE WORLD

23. A MODEL
IS ABOUT USEFULNESS
AROUND A SPECIFIC
SET OF PROBLEMS

24. A MODEL
IS ADAPTED
TO AN USAGE

25. ABSTRACTION

26. ABSTRACTION
IS TO FORGET THE
NON SIGNIFICANT DETAILS

27. ABSTRACTION
IS TO FORGET THE
NON SIGNIFICANT DETAILS
AND FOCUS ON
THE ESSENTIALS

28. AN ABSTRACTION
OF REALITY,
NOT A REFLECTION OF REAL
LIFE

29. PARIS TOURIST MAP

30. PARIS METRO MAP

31. WRONG MODELS

32. WRONG MODELS
CAUSE MASSIVE
ACCIDENTAL COMPLEXITY

33. WHAT
ARE ITS
USAGE ?
PARIS TOURIST AND TRANSPORT MAP ?

34. A MODEL
CONTAINS ONLY
WHAT IS RELEVANT

35. MODELS ARE NEITHER
“RIGHT” OR “WRONG”
BUT SOME ARE
USEFUL THAN OTHERS

36. DESIGN IS
MAKING
DECISIONS

37. DESIGN
IS THE ART OF
TRADE-OFF

38. THE DOMAIN MODEL

39. THE DOMAIN MODEL
IS AN ABSTRACTION
OF THE
PROBLEM DOMAIN

40. Domain
Domain Model
The reality
An abstraction of reality
designed to manage
complexity for specific
business cases
A projection
of the Real Domain
THE PROBLEM SPACE THE SOLUTION SPACE

41. SOFTWARE
DEVELOPMENT
AND ITS PROBLEMS

42. SCRUM PRODUCT BACKLOG

43. PRESSURE TO DELIVER
SOFTWARE RELEASES
ON A RELENTLESS
SCHEDULE

44. LACK
OF DESIGN

45. FOCUS ON SOLUTION SPACE
Language Framework
LibrariesInfra

46. CV
DRIVEN
APPROACH

47. POOR
COLLABORATION

48. UML JAVA / C#
POOR SYNCHRONIZATION
BETWEEN MODELS

49. Broken, slow and locking the database

51. WRONG
LEVEL OF
ABSTRACTION

52. WHAT DOES
THE APPLICATION
DO ?
WHAT IS THE
APPLICATION
ABOUT ?

53. COMPLEX DOMAINS
CAN BECOME
DIFFICULT TO MANAGE

54. It works but no one
knows how
Initial software
incarnation fast to
produce
time
without care and
consideration

55. DATA
MODELS
INSTEAD OF
DOMAIN
MODELS

56. MOST DEVELOPERS
HAVE NEVER SEEN
A DOMAIN MODEL

57. THEY’VE ONLY SEEN
DATA MODELS

58. Database centric Architecture

60. BIG BALL OF MUD

63. IMPROVE YOUR CRAFT

64. IMPROVE YOUR CRAFT
AND INCREASE
YOUR SUCCESS ON
PROJECTS

65. CREATE BETTER SOFTWARE
MORE EASILY

66. CREATE BETTER SOFTWARE
MORE EASILY
BY FOCUSING ON THE
DOMAIN INSTEAD OF
THE TECHNOLOGY

67. TO FOCUS ON
BUSINESS VALUE

68. DDD
as a
bridge
PROBLEM
SPACE
SOLUTION
SPACE

69. A TOOLSET : A COLLECTION OF PATTERNS, PRINCIPLES & PRACTICES

70. COLLABORATIVE
MODELING
STRATEGIC
DESIGN
(Context Mapping)
TACTICAL
DESIGN
(Building Blocks,
patterns)
DDD BREAKDOWN

71. PROBLEM SPACE
DOMAIN

72. COLLABORATIVE
DESIGN

73. CREATING
A USEFUL MODEL
IS A
COLLABORATIVE
EXPERIENCE

74. MANY
KNOWLEDGE CRUNCHING
TECHNIQUES

75. MANY
KNOWLEDGE CRUNCHING
TECHNIQUES
TO EXPLORE DOMAINS

76. MANY
KNOWLEDGE CRUNCHING
TECHNIQUES
TO EXPLORE DOMAINS
AND LEARN THE INTENT OF
THE BUSINESS

77. KNOWLEDGE CRUNCHING
IS THE ART
OF DISTILLING
RELEVANT INFORMATION

78. KNOWLEDGE CRUNCHING
IS THE ART
OF DISTILLING
RELEVANT INFORMATION
FROM
THE PROBLEM DOMAIN

79. CLARIFYING QUESTIONS
• What do you mean by … ?
• What might lead someone to
do / need .. ?
• What else might happen ...?

80. THIS LEADS TO
THE DISCOVERY OF
IMPORTANT CONCEPTS

81. ALLOWS THE TEAM TO
UNDERSTAND
WHAT IS NOT IMPORTANT
AND CAN BE EXCLUDED
FROM THE MODEL

82. DDD
IS
EXPLORATORY

83. BUSINESS USERS
ARE BUSY
PEOPLE

84. BUSINESS USERS
CAN ALSO FIND TIRING
AND DEEM IT
UNPRODUCTIVE

85. MAKE YOUR
KNOWLEDGE CRUNCHING
SESSIONS
FUN AND INTERACTIVE

86. INTRODUCE
SOME
FACILITATION GAMES

87. INTRODUCE SOME
FACILITATION GAMES
AND OTHER
FORMS OF REQUIREMENTS
GATHERING TO ENGAGE
YOUR AUDIENCE

88. EVENT STORMING

89. EventCommand
Actor
Question ?

90. THE GOAL OF
EVENT STORMING
IS TO DISCOVER

91. THE GOAL OF
EVENT STORMING
IS TO DISCOVER
NOT TO MAKE
A DECISION

92. DRIVE KNOWLEDGE
CRUNCHING
AROUND THE MOST
IMPORTANT USE CASE
OF THE SYSTEM

93. Jeff Patton Alberto Brandolini Eric Evans

94. EMPLOY
KNOWLEDGE CRUNCHING
TECHNIQUES
TO PRODUCE
EFFECTIVE MODELS

95. CHALLENGE
YOUR MODEL

96. DON’T STOP
AT YOUR
FIRST IDEA

97. YOU WON’T GET IT RIGHT
THE FIRST TIME

98. GOOD DESIGN
IS IMPERFECT DESIGN

99. THE ONLY WAY
TO LEARN A COMPLEX SYSTEM
IS TO LIVE AND TO INTERACT
WITH IT

100. EXPERTS
DOESN’T KNOW
EVERYTHING

101. DON’T WAIT PERFECT TEAM

102. DON’T WAIT PERFECT TEAM
DON’T WAIT PERFECT PEOPLE

103. USE BDD
TO FOCUS ON
THE BEHAVIOR OF THE
APPLICATION AROUND
CONCRETE SCENARIOS

104. UBIQUITOUS
LANGUAGE

105. UBIQUITOUS LANGUAGE

106. VARIOUS EXPRESSIONS
OF THE MODEL
ARE BOUND
BY THE SAME LANGUAGE

107. WHEN MODELING,
EVERYONE SHOULD APPLY
A SHARED LANGAGE RICH
IN DOMAIN SPECIFIC
TERMINOLOGY

108. UBIQUITOUS LANGUAGE
IS A
SHARED LANGUAGE

109. UBIQUITOUS LANGUAGE
IS A
SHARED LANGUAGE
USED BY ALL TEAM MEMBERS

110. UBIQUITOUS LANGUAGE
IS A
SHARED LANGUAGE
USED BY ALL TEAM
MEMBERS TO CONNECT
ALL ACTIVITIES OF THE
TEAM WITH THE SOFTWARE

111. BOUND BY
LANGUAGE
EXPRESSED AS
DIAGRAMS
EXPRESSED IN
CONVERSATION
EXPRESSED AS
DOCUMENTATION
EXPRESSED AS
CODE
THE
DOMAIN
MODEL

112. UML JAVA / C#
Ubiquitous
Language

113. UBIQUITOUS LANGUAGE
IS A KEY TOOL

114. SUBDOMAINS

115. DOMAIN
IS OFTEN COMPLEX

116. THE DOMAIN

118. NOT ALL THE PART
OF THE PROBLEM
NEED PERFECT SOLUTION

120. DISTILL LARGE PROBLEM
DOMAINS TO REVEAL
THE CORE OPPORTUNITY

121. DISTILL IN SUBDOMAINS

122. FOCUS EFFORT
WHERE IT MATTERS

123. IDENTIFY
THE CORE DOMAIN
AND THE CORE COMPLEXITY

125. OSS Lib
COTS
Contarcting
“Secret Source”

126. SOLUTION SPACE

127. MOVE BUSINESS
IN YOUR CODE

128. DDD IS A PROCESS
THAT ALIGNS
YOUR CODE
WITH THE REALITY OF
YOUR PROBLEM DOMAIN

129. MAKE
THE IMPLICIT EXPLICIT

130. THE CODE MODEL IS THE
PRIMARY EXPRESSION OF
THE DOMAIN MODEL

131. DDD
ONLY REQUIRES
THE MODEL
TO BE KEPT ISOLATED FROM
TECHNICAL COMPLEXITIES

132. CAR TIRE SOLD
Gauranteed
one year
SEND A DISCOUNT
COUPON TO THE
CUSTOMER
Yes

133. public class GuaranteedOneYearDeliveryOffer
{
public void after(CarTireSold delivery)
{
if (delivery.TimeTimeTaken.Exceeded(oneYear)
{
sendCarBreakDiscountCouponTo(delivery.Customer) ;
}
}
}
Don’t focus on technical details …
…talk in domain terns.

134. DDD
IS TECHNICALLY AGNOSTIC

137. THE CODE
AND THE DOMAIN MODEL
ARE KEPT IN SYNERGY

138. THE CODE
IS THE MODEL

139. THE CODE
IS THE TRUTH

140. BOUNDED CONTEXT

141. DECOMPOSE
THE SOLUTION SPACE
FOR COMPLEX
OR LARGE MODELS

142. DECOMPOSE
THE SOLUTION SPACE
AND DEVELOP MULTIPLE
MODELS WITHIN EXPLICIT
BOUNDARIES

144. CUSTOMER
CONTEXT
<<SALES>>
Center of
interest
CONTEXT
<<Accounting>>
Method of
payment
CONTEXT
<<Order Shippment>>
Address Availability
A SINGLE LARGE AMBIGUOUS MODEL
BUSINESS
USE CASE
BUSINESS
USE CASE
BUSINESS
USE CASE

145. CONTEXT
MATTERS

146. CONTEXT
<<SALES>>
Customer: Center of
interest
CONTEXT
<<ACCOUNTING>>
Customer: Method of
payment
CONTEXT
<<ORDER SHIPMENT>>
Customer: Address
Availability
MULTIPLE SMALLER EXPLICIT MODELS

147. A BOUNDED CONTEXT

148. A BOUNDED CONTEXT
IS A SEMANTIC CONTEXTUAL
BOUNDARY

149. A BOUNDED CONTEXT
PROTECTS THE DOMAIN
MODEL AND DEFINES THE
APPLICABILITY BOUNDARY

150. DOMAIN
MODEL
Bounded
Context

151. BOUNDED CONTEXT
IS THE CONDITIONS
WHICH
A PARTICULAR MODEL
IS DEFINED AND APPLICABLE

152. GENERALLY
BOUNDED CONTEXTS
MATCH
SUBDOMAINS

153. ALIGN BOUNDED CONTEXTS TO SUBDOMAINS
Bounded
ContextBounded
Context
Bounded
Context
Bounded
Context

154. ALIGN TEAMS
TO
BOUNDED CONTEXTS

155. ARCHITECTURE STYLE

156. DDD
DOESN’T DICTATE
ANY SPECIAL
ARCHITECTURAL PATTERNS

157. PATTERNS
USED TO IMPLEMENT
BOUNDED CONTEXTS
SHOULD BE APPROPRIATE
TO THE COMPLEXITY

158. MANY MODELS
• Rich Domain Model
• CRUD Model
• Anemic Model
• Transaction Script Model
• etc

159. CHOOSE
THE RIGHT
DOMAIN
MODEL

160. BOUNDED CONTEXTS with MODELS
CRUD
RICH
MODEL
ANEMIC ANEMIC

161. HEURISTICS

162. PRACTICAL METHOD
NOT GUARANTEED TO BE
OPTIMAL OR PERFECT

163. PRACTICAL METHOD
NOT GUARANTEED TO BE
OPTIMAL OR PERFECT
BUT SUFFICIENT FOR
IMMEDIATE GOALS

164. o Favorite Algorithms
o Favorites Solutions
o Favorites Approaches
o Our Mental Models
o Patterns
o etc

165. DO NOT BE BLOCKED ON
YOUR HEURISTICS
• System Layers
• ORM
• IOC
• Anemic Behaviours

166. HEXAGONAL
ARCHITECTURE

167. INSIDE
OUTSIDE

168. DOMAIN
INFRA
(HTTP, MoM, Databases, etc)

169. DOMAIN
INFRA
(Ports & Adapters, DMZs)

170. Hexagonal / Onion / Ports-And-Adapters Architecture

171. STRATEGIC DESIGN

172. COMPOSE
BOUNDED CONTEXTS
TO CREATE APPLICATIONS

173. USER INTERFACE
APPLICATION
BOUNDED CONTEXT A BOUNDED CONTEXT B
BOUNDED CONTEXT C
USER INTERFACE

175. INTEGRATE MODELS
Mapping

176. INTEGRATION
PATTERNS ENABLE
BOUNDED CONTEXTS
TO COMMUNICATE

177. TACTICAL PATTERNS
• Value Objects
• Entities
• Aggregates
• Repositories
• Domain Services
• Application
Services
• Domain Events

178. DDD
IS NOT
A PATTERN LANGUAGE

179. AGGREGATE

180. AGGREGATE
IS A CLUSTER OF DOMAIN
OBJECTS

181. AGGREGATE
IS A CLUSTER OF DOMAIN
OBJECTS
THAT CAN BE TREATED AS
A SINGLE UNIT

182. AGGREGATE
IS A COLLECTION OF DATA
THAT WE INTERACT WITH
AS A UNIT

183. CONCLUSION

184. ALWAYS
CONNECT YOUR
DECISIONS
TO YOUR
BUSINESS
OBJECTIVES

185. GO FURTHER