The collaboration between business people and the development teams is often distorted by implementation concerns, past habits and past constraints. This is harmful, especially if you have major ambitions. To achieve better software, developers could try to reverse-engineer from the given specifications, or you could embark into a joint exploration of the domain towards its first principles, which are the main concepts or assumptions that cannot be deduced from anything else. Join Cyrille on this topic to find out how it can help your most challenging digital initiatives!

1. Domain Modelling for
DIGITAL
Transformations
@cyriux
Cyrille Martraire

2. #FlowCon

3. Low BS

5. You still need DDD
for your Digital
Transformations!

6. Developer / Consultant
Socio-Technical Architect
PARIS
Since 1999
@cyriux
Cyrille Martraire

7. Paris Software Crafters
Community since 2011
http://www.meetup.com/paris-software-craftsmanship/

8. arolla.fr @arollafr

9. arolla.fr @arollafr
TDD
BDD
DDD

11. Transformations

12. @cyriux
BUY MY BOOK!

14. MY KEY MESSAGE

15. DOMAIN-DRIVEN

16. DOMAIN-DRIVEN

17. DOMAIN-DRIVEN
too gentle

18. EVERYONE (incl. DEVs)
LEARNING ABOUT
THE BUSINESS DOMAIN

19. COLLECTIVELY
INVESTIGATING
THE BUSINESS DOMAINS…

20. …INTO USEFUL
& SHARED
CONCEPTUAL MODELS

21. CONCEPTUALISE A
DOMAIN MODEL
AS A THEORY

22. ALL THIS
too gentle

23. SPOT THE
FIRST PRINCIPLES
BEHIND THE THEORY

24. CHALLENGE THE
FIRST PRINCIPLES

25. TO SUGGEST CHANGES TO
THE BUSINESS PROCESSES

26. TO TURN THEM TO
DIGITAL-NATIVE BUSINESSES

27. FROM
DOMAIN-DRIVEN SOFTWARE
TO
SOFTWARE-AUGMENTED BUSINESS

28. TO EMBRACE

31. why this talk?

33. Collaboration between
business people &
development teams

34. Case by Case

35. One User Story

36. Another User Story

37. Some Other User Stories

38. Even More User Stories

39. A LOT of User Stories…

40. … all Special Cases of a General Case!
X=

41. X
One Model To Rule Them All
Ribbon Costume

42. HUMAN
COMPILER
Compiling from high-level to low-level
manually
Anti-pattern

43. Collaborate on the general case!
X=

44. WHY?

45. LACK OF
TRUST”Devs are not able to understand”

48. INTRODUCING
THE WATERLINE

49. Design vs Requirement
If it's your decision to make,
then it's 'design'; if it's not,
then it is a requirement
— Alistair Cockburn
http://alistair.cockburn.us/A+requirement+is+a+relationship+to+a+decision

50. The design waterline
requirements
design waterline

51. requirements
design current
waterline CODE
SPECIFICATIONS
The design waterline

52. requirements
design
All the way up 4eva…
SPECIFICATIONS
SOMEONE ELSE’S IN POWER

53. requirements
design current
waterline CODE
SPECIFICATIONS
The collaboration level

54. requirements
design current
waterline LABORIOUS
CODE
SPECIFICATIONS
What happens too often

55. requirements
design current
waterline
HUMAN
COMPILER
HOW BUSINESS
PEOPLE THINK
SPECIFICATIONS
Accidental Complexity (Biz people)

56. requirements
design current
waterline
HUMAN
COMPILER
ONE GENERAL CASE
MANY
CONSEQUENCES
Accidental Complexity (Biz people)

57. requirements
design current
waterline
ONE GENERAL CASE
MANY
CONSEQUENCES
Accidental Complexity (Biz people)
X

58. RAISE THE
WATERLINE

59. RAISE THE
WATERLINE
(mutually)

60. You don’t have
to dumb down
the domain, you
know.

61. requirements
design new
waterline
Mutual Higher-Level Communication
SMARTER
CODE
SPECIFICATIONS
XX
X

62. More generally…

63. SOLUTION
STATEMENTThe expressed need is frequently a
solution dressed up as a problem

64. Challenging
the expressed ”needs”

65. How do I do that?

66. POWERFUL
QUESTIONS

68. OTHERS
CONFIGURE
THIS MANUALLY
GOOGLE SRE
CONFIGURES
HERE
GOOGLE
AUXON
automated capacity
planning framework
https://landing.google.com/sre/book/chapters/software-engineering-in-sre.html

69. GOOGLE Auxon - DC resources allocations
Moving from concrete resource demands to motivating reasons in order
to arrive at the true capacity intent often requires several layers of
abstraction.
1. I want 50 cores in clusters X, Y, and Z for service Foo.
2. I want a 50-core footprint in any 3 clusters in geographic region YYY
for service Foo.
3. I want to meet service Foo’s demand in each geographic region,
and have N + 2 redundancy.
4. I want to run service Foo at 5 nines (99.999%) of reliability A
In Google’s experience, we tend to achieve the best wins as they cross
to step 3. Particularly sophisticated services may aim for step 4.
WHY?
WHY?
WHY?
https://landing.google.com/sre/book/chapters/software-engineering-in-sre.html

70. Facilitation Questions Cards

72. Sometime developers
become human
compilers too…

73. BTW: Accidental Complexity (devs)
requirements
design
waterline
deductive
implementation
LABORIOUS
CODE
HUMAN
COMPILER
SPECIFICATIONS

75. What’s wrong
with that?

76. What’s wrong
with that?Too muchcode!

77. What’s wrong
with that?Too muchcode! Can’t code each
possible case!

78. What’s wrong
with that?
Not maintainable!
Too muchcode! Can’t code each
possible case!

79. What’s wrong
with that?
Not maintainable!
Too muchcode! Can’t code each
possible case!

80. The antidote

81. Refactoring skills
Test-Driven Development skills

82. Concrete-Scenario-Driven
(TDD, BDD)
requirements
design
waterline
derive
concrete
scenarios
(deduction) TEST CASES
TRIANGULATION
refactor to
general code
(induction)
SPECIFICATIONS

83. Dev’s super power is to be
good at exploiting
regularities through
refactoring

84. Which means they can help
business people at that

85. requirements
design
DEVS
NON-DEVS
Co-construction!

88. Refactoring to
the general
case is nice…

89. But what
about all the
other business
rules?

90. But what
about ALL THE
other business
rules?

91. ARBITRARY
RULES
OBSESSION
But what
about all the
other business
rules?

92. Business
=
CRUD
+
rules
ARBITRARY
RULES
OBSESSION

93. Business
=
CRUD
+
rules
ARBITRARY
RULES
OBSESSION
Bunch of
data fields
Piles of IF
statements

94. BIG BAG OF
BUSINESS
RULES
Domain model as-a

95. You cannot get
smarter domain models if
you believe the domain is
mostly arbitrary!

96. Do you believe the
world is just noise,
or full of hidden
regularities?

97. Code can be small
YET still supports a
LOT of behaviours

98. Domain Modelling is
a quest to eradicate
arbitrary business
rules!

99. Programming as Theory-
Building
— Peter Naur (1985)
http://pages.cs.wisc.edu/~remzi/Naur.pdf

100. DOMAIN MODEL
as-a
THEORY

101. To understand
To explain
To predict

102. A widely accepted theory
Murray Gell-Mann
Nobel 1969

103. A Finite Set of Quarks

104. Quarks Compose into
bigger particles
Neutron Proton

105. Quarks Predict Unknown particles
Neutron Proton
and
many others…
GENERATIVE power

106. Why it matters?

107. a Theory is
Concise
but their consequences are
EXTENSIVE

108. a Theory is
Concise
but its consequences are
EXTENSIVE

109. A Finite Set of Quarks

110. Many particles
Neutron Proton
and
many others…

111. First Principles / Maths
Integrals Differentiation
CONCISE (slow)
”a measure of the rate of change”

112. Few Principles, Many Consequences
Integrals Differentiation
Large (FAST)

113. a Theory is
Concise
but its consequences are
EXTENSIVE

114. EXTENSIVE
requirements
design
Surface of the waterline

115. LOT OF CODE
requirements
design
Surface of the waterline

116. Concise
Surface of the waterline
requirements
design

117. Concise
Surface of the waterline
requirements
design
fewer code

118. requirements
design

119. Theory

120. +
Regularities
Found
Residual
Mess
But many business domains are messy

121. Theory
+
Residual
Mess

122. +
Theory
Residual
Mess
SMALL SMALL

123. +
Theory
Residual
Mess
TESTABLE TESTABLE

124. +
Theory
Residual
Mess
MAINTENABLE MAINTENABLE

125. +
Theory
Residual
Mess
CHALLENGEABLE! CHALLENGEABLE!

126. BUT…

127. To recognise all regularities…

128. …you must have the whole
picture in mind.

129. MIND THE
DISCOVERY PATH

130. ”triangles always
blue”

131. Or red

132. Discovery with the full memory
”triangles
are either blue,
green, red”

133. I need to add
”green triangles”
somewhere into the
system
One case at a time: no insight

134. ”triangles
are either blue,
green, red”
Observing all diversity at once
makes insights obvious

135. Observing the
DIVERSITY at once
makes insights
obvious

136. Feature 1 Feature 2 Feature N
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Story map

137. Feature 1 Feature 2 Feature N
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Story map
INITIAL DESIGN ON 1 SINGLE CASE
:(

138. Feature 1 Feature 2 Feature N
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Story map
EXPLORING QUICKLY WHAT’S NEXT
User
Story?

139. Feature 1 Feature 2 Feature N
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Story map
A BIT OF BOTH
User
Story?

140. T-SHAPED
EXPLORATION

141. BUT CYRILLE…
We’re agile, we should
be able to change
anything anytime!

142. First layer of bricks matters more…

143. This should not be true but it is,
for many bad reasons.

145. SKEUOMORPHIC
MODEL

147. ”Preservation of the familiar
through technological change”

148. characteristic
"wooden" beams
1250–546 BC

149. At some point we have to learn to
rid of skeuomorphism

150. It takes time to see, learn &
accept novelty

151. PATH-DEPENDENT
EVOLUTION

152. Long ago

153. NEW: The factory line

154. Mass
production

155. NEW: robot!

156. More robots!!

157. More robots!!!

158. A line of robots…

159. A line of robots…

160. Sum of LOCAL
optimizations
≠
GLOBAL
Optimization

161. A line of robots…
COULD DO
BETTER
THAN THIS

162. THINK
DIGITAL-
NATIVE
FAB

163. Factory reboot
laser
cutter
Versatile
Robot
Skilled
Worker

164. laser
cutter
Versatile
Robot
Skilled
Worker
Digital Fab-native

166. laser
cutter
Versatile
Robot
Skilled
Worker
Fewer Machines

167. laser
cutter
Versatile
Robot
Skilled
Worker
Mass Customization

168. New technology:
Opportunity to review /
change the business
processes

170. Theory

171. Theory builds on top of
principles

172. FIRST-
PRINCIPLES

173. Aristotle: a first principle is the "first basis
from which a thing is known”

174. First Principles Thinking
…one of the most effective strategies you can
employ for breaking down complicated
problems and generating original
solutions.
https://jamesclear.com/first-principles
Deconstruct then reconstruct.

175. Elon Musk on First Principles
[With first principles] you boil
things down to the most
fundamental truths … and then
reason up from there."
http://www.businessinsider.fr/us/elon-musk-first-principles-2015-1/

176. Principles that we we often
take for granted

177. Principles that we can
challenge…

178. First Principles
Thinking / Einstein
Einstein questioned the
assumption that time and
space were absolute.
1905

179. Not continuous improvements
Continuous improvement tends to occur within the
boundary set by the original vision.
https://jamesclear.com/first-principles

180. Deconstruct past models
to reconstruct
new innovative models
when designing software

181. RADICAL
RE-INVENTIONfrom first principles

182. WHAT IF WE
STARTED FROM
SCRATCH?

183. CREDIT RISK FROM FIRST PRINCIPLES
RISK BUREAU
GUARANTEES
VALUE OVER TIME
MONEY LENT
OVER TIME
IS IT BALANCED?

184. PAYMENT FROM FIRST PRINCIPLES
PAYMENT RISK
COMMITMENT TO
SHIP PRODUCT NOW
PROMISE TO SEND
MONEY LATER
”NON REPUDIATION”

185. FINANCE FROM FIRST PRINCIPLES
Do whatever with money / risk moving hands, as long as you can get
”FEES”

186. requirements
design
Radically From First Principles
(Ignoring the traditions)
FIRST
PRINCIPLES OF
THE BUSINESS
CO-DESIGNED
SOFTWARE

187. Because software is different
than what was before…

188. No such a thing as
Technology-Agnostic Domains
An office pool in the 1950s. Underwood & Underwood/Corbis

189. UNDERLYING
TECHNOLOGYas-a-legacy influence

190. Calculating number of days between dates is
difbicult
→ 30/360 day count basis calculation as a
”simpli5ication" (LOL) when calculating the
number of days in months
Legacy Corruption

191. An office pool in the 1950s. Underwood & Underwood/Corbis

192. Domains are still shaped by
the previous technology:
bureaucracy
An office pool in the 1950s. Underwood & Underwood/Corbis

193. Legacy Assumptions
Human time is precious so we optimise how to
use it sparsely (but machine time is not)

194. When 80% of requests are
fully automated…

195. …does it still makes sense
to have a workflow
between (mostly) function
calls?

196. #NoWorkflow

197. DIGITAL-NATIVE
BUSINESSES

199. /! Political Risk /!
Who’s gonna sign off the decision to make radical
changes to business processes?
Discovering a modelling breakthrough is only half of the
total effort; the other half is communicating and convincing
other people (business sponsors, managers…) to accept
the associated risk of novelty.

200. in closing

201. RAISE THE
WATERLINE

202. EXPECT
UNTOLD
REGULARITIES

203. Advocate
Domain-Driven
Design

204. Build theories,
not just lists of
business rules

205. LEARN TO
THINK FROM
FIRST
PRINCIPLES

207. Embrace
DIGITAL
Transformations

208. to
SOFTWARE-
AUGMENTED
BUSINESSES

209. @cyriux
Cyrille Martraire
Thanks!

212. Follow me @cyriux
Slides: slideshare.net/cyriux
Blog: cyrille.martraire.com
We offer training, coaching & consulting on DDD, BDD, TDD