As developers we are often explained the business domain in a way that is corrupted by implementation concerns or past constraints. This is harmful. To achieve better domain models, we often have to reverse-engineer. Alternatively, we can also explore the domain from its first principles, which are the main concepts or assumptions that cannot be deduced from anything else. Reaching for first principles takes more mental energy, but is also the key to more radical innovations beyond small incremental evolutions. It also turns domain modeling into a fun puzzle to solve. Through examples you will discover how domains can be deconstructed towards their essential first principles, in order to reconstruct sharp domain models.

1. @cyriux
Cyrille Martraire
Domain Modelling towards
First Principles

2. DDD Europe

3. Low BS

5. DDD practioners: we
need you for Digital
Transformations!

6. Passionate developer
Deliberate Designer
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

10. ”The DDD guy from
Paris”

12. MY KEY MESSAGE

13. DOMAIN-DRIVEN

14. DOMAIN-DRIVEN
too gentle

15. LEARN THE DOMAIN

16. USE YOUR
DOMAIN-DRIVEN SKILLS

17. REVERSE-ENGINEER THE
BUSINESS DOMAINS

18. INTO USEFUL
CONCEPTUAL MODELS

19. ALL THIS
too gentle

20. CONCEPTUALISE A
DOMAIN MODEL
AS A THEORY

21. SPOT THE
FIRST PRINCIPLES
BEHIND THE THEORY

22. CHALLENGE THE
FIRST PRINCIPLES

23. TO SUGGEST CHANGES TO
THE BUSINESS PROCESSES

24. TO TURN THEM TO
DIGITAL-NATIVE BUSINESSES

25. TO EMBRACE

28. why this talk?

30. We are given work

31. Case by Case

32. One User Story

33. Another User Story

34. Some Other User Stories

35. Even More User Stories

36. A LOT of User Stories…

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

38. X
What you have in mind
Ribbon Costume

39. HUMAN
COMPILER
Please describe the problem, not
its multiple consequence
Anti-pattern

40. Please give me the general case!
X=

41. This is a job for machines,
not for Developers

42. WHY?

43. SOLUTION
ENVYEveryone wants to be the problem
‘solver’, even when it’s not their skills

44. LACK OF
TRUST”They’re not able to understand”

46. INTRODUCING
THE WATERLINE

47. 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

48. The design waterline
requirements
design waterline

49. requirements
design current
waterline LABORIOUS
CODE
HOW BUSINESS
PEOPLE SPECIFY
What happens too often

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

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

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

53. RAISE THE
WATERLINE

54. RAISE THE
WATERLINE
(mutually)

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

56. requirements
design new
waterline
Mutual Higher-Level Communication
SMARTER
CODE
HOW BUSINESS
PEOPLE SPECIFY

57. More generally…

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

59. Challenging
the expressed ”needs”

60. How do I do that?

61. POWERFUL
QUESTIONS

63. ➡ in your goodies bags
Facilitation Questions Cards

65. Sometime we developers
become human
compilers too…

66. BTW: Accidental Complexity (devs)
requirements
design
waterline
deductive
implementation
LABORIOUS
CODE
HUMAN
COMPILER
HOW BUSINESS
PEOPLE SPECIFY

68. What’s wrong
with that?

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

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

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

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

73. You know the antidote

74. Refactoring skills
Test-Driven Development skills

75. Concrete-Scenario-Driven
(TDD, BDD)
requirements
design
waterline
derive
concrete
scenarios
(deduction) TEST CASES
HOW BUSINESS
PEOPLE SPECIFY
TRIANGULATION
refactor to
general code
(induction)

76. Our super power is to be
good at exploiting
regularities through
refactoring

77. Which means we can help
business people at that

79. Domain Experts
not really experts

80. RAISE THE
WATERLINE
(yourselves)

81. requirements
design current
waterline LABORIOUS
CODE
HOW BUSINESS
PEOPLE SPECIFY
Current situation

82. requirements
design current
waterline
THE WAY BUSINESS
REALLY WORKS
(TACIT KNOWLEDGE)
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

83. requirements
design
inductive
exploration
(speculative)
current
waterline
Reverse-Engineering Investigation
(Progressing towards Higher Principles)
THE WAY BUSINESS
PEOPLE THINK
(MAY BE TACIT)

84. requirements
design
inductive
exploration
(speculative)
current
waterline
Reverse-Engineering Investigation
(Progressing towards Higher Principles)
THE WAY BUSINESS
PEOPLE THINK
(MAY BE TACIT)
YOUR
JOB

85. requirements
design
inductive
exploration
(speculative)
current
waterline
agree with
experts
Reverse-Engineering Investigation
(Progressing towards Higher Principles)
YOUR
JOB

86. requirements
design
inductive
exploration
(speculative)
current
waterline
raise the
waterline!
agree with
experts
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

87. requirements
design new
waterline
MORE POTENTIAL FOR
SMARTER DESIGN
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

88. Smarter domain description,
Smarter implementation

89. MOST TEAMS
CONFIGURE
THIS MANUALLY
GOOGLE SRE
CONFIGURES
HERE

90. 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

91. Will hardly happen unless you
drive that

92. Developers are
the professionals
of induction

93. Example please!

94. Teams members
Workers assignments
Categories
Bank holidays
Currencies
Industry Classifications
Countries, Regions
Include / Exclude lists
Preferences
Access rights
Con_iguration Lists

95. Lists in admin website

96. Somebody has to manage
all these big lists…

97. Let’s just add a
CRUD page, as
usual.

98. RAISE THE
WATERLINE

99. WHY this list?

100. WHERE does it
come from?

101. From other
lists, post-
processed!

102. Web feeds
Spreadsheets
Data already in DB
- merged
- filtered

103. + =
raw lists processing MY list

104. Imagine you work as a dev for an
insurance company…

105. Insurance Broker Portfolio
Configuration
”Each Insurance Broker has a list
of contracts they manage: their
”portfolio” of contracts.”
They configure it manually on a
web page.

106. Insurance Broker Portfolio
Configuration
”Each Insurance Broker has a list
of contracts they manage: their
”portfolio” of contracts.”
They configure it manually on a
web page.
Where does this list come from?

107. WHERE does it
come from?

108. Turns out
• They did searches during their setup
• Search all contracts by corporate, for the
few corporates they manage
• Their portfolio is every contracts with these
corporates.
• Except the VIP contracts, managed by the
head of sales.

109. From other
lists, post-
processed!

110. SELECT * FROM contracts
WHERE contract.corporate IN my-accounts
AND !contract.isVIP
Nothing fancy here.

111. SELECT * FROM contracts
WHERE contract.corporate IN my-accounts
AND !contract.isVIP
SMALL list

112. And now for a new pedantic word…

113. Portfolio de_ined as…
+ =
raw lists MY list
EXTENSIONAL
curation
criteria
INTENSIONAL

114. An intensional
definition … by
specifying necessary
and sufficient
conditions

115. "bachelor"
=
"unmarried man"

116. PREDICATE
evaluate(something): boolean

117. An extensional
definition … by
listing everything

118. "bachelor"
=
listing of all the
unmarried men in
the world

119. "bachelor"
=
listing of all the
unmarried men in
the world
Ooops!!!

120. Enumerablefor each: element

122. EXTENSIONAL
OBSESSION

124. HEURISTICS:
CONSIDER THE
INTENSIONAL
ALTERNATIVE

125. HIGHER LEVEL of LANGUAGE
PORTFOLIO AS
CRITERIA
PORTFOLIO AS
LIST OF CONTRACTS

126. PORTFOLIO AS
LIST OF CONTRACTS

127. SELECT * FROM contracts
WHERE contract.corporate IN my-accounts
AND !contract.isVIP
INTENSIONAL
Extensional

128. managed
list of corporates
VIP tag on some contracts
+
PORTFOLIO AS
CRITERIA

129. problem solved :)

131. This modelling
trick is nice…

132. But what
about all the
other business
rules?

133. But what
about ALL THE
other business
rules?

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

135. Business
=
CRUD
+
rules
ARBITRARY
RULES
OBSESSION

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

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

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

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

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

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

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

143. DOMAIN MODEL
as-a
THEORY

144. To understand
To explain
To predict

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

146. A Finite Set of Quarks

147. Quarks Compose into
bigger particles
Neutron Proton

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

149. Why it matters?

150. a Theory is
Concise
but their consequences are
EXTENSIVE

151. a Theory is
Concise
but its consequences are
EXTENSIVE

152. A Finite Set of Quarks

153. Many particles
Neutron Proton
and
many others…

154. a Theory is
Concise
but its consequences are
EXTENSIVE

155. EXTENSIVE
requirements
design
Surface of the waterline

156. LOT OF CODE
requirements
design
Surface of the waterline

157. Concise
Surface of the waterline
requirements
design

158. Concise
Surface of the waterline
requirements
design
fewer code

159. requirements
design

160. Theory

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

162. Arbitrary = Messy Domains
Eric Evans: DDD is Not for Perfectionists https://www.infoq.com/news/2017/02/ddd-perfectionists
The Spill Zone pattern: to cover the
remaining messy cases, e.g. a function
casesWeHaventFiguredOut() with only
IF-THEN inside — Eric Evans at DDDEU 2017

163. (like Circuit Breaker,
but for design)

164. Theory
+
Residual
Mess

165. +
Theory
Residual
Mess
SMALL SMALL

166. +
Theory
Residual
Mess
TESTABLE TESTABLE

167. +
Theory
Residual
Mess
MAINTENABLE MAINTENABLE

168. +
Theory
Residual
Mess
CHALLENGEABLE! CHALLENGEABLE!

169. But to reverse-engineer it all…

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

171. MIND THE
DISCOVERY PATH

172. ”triangles always
blue”

173. Or red

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

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

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

177. Observing the
DIVERSITY at once
makes insights
obvious

178. 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

179. 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
:(

180. 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?

181. 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?

182. T-SHAPED
EXPLORATION

183. LIKE IN TDD!
Driving the
implementation and
its design by ordering
the tests strategically

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

185. First layer of bricks matters more…

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

189. LEGACY
CORRUPTION

190. ”We've always
done like that!”

191. Legacy Corruption
People distorted their business concepts to cope
with the constraints of their legacy software
”A Tricycle is a kind of Truck because only the type
Truck has the 7ield to specify the ‘number of
wheels’”

192. Legacy Assumptions
BATCHES take a lot of time and fail often, so we
need to store all data at each step for human
inspection and recovery (Data Obsession)

193. +
Theory Residual
Mess
DETOX
+ LEGACY
CORRUPTION
ANTIDOTE

196. SKEUOMORPHIC
MODEL

198. ”Preservation of the familiar
through technological change”

199. characteristic
"wooden" beams
1250–546 BC

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

201. PATH-DEPENDENT
EVOLUTION

202. Long ago

203. Mass
production

204. The factory line

205. NEW: robot!

206. More robots!!

207. More robots!!!

208. A line of robots…

209. A line of robots…

210. Sum of LOCAL
optimizations
≠
GLOBAL
Optimization

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

212. THINK
DIGITAL-
NATIVE
FAB

213. Factory reboot
laser
cutter
Versatile
Robot

214. Digital Fab-native
laser
cutter
Versatile
Robot

216. Fewer Machines
laser
cutter
Versatile
Robot

217. Mass Customization
laser
cutter
Versatile
Robot

218. Opportunity to review /
change the business
processes

219. Theory build on top of
principles

220. FIRST-
PRINCIPLES

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

222. 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.

223. 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/

224. Principles that we can
challenge…

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

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

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

228. +
Theory
Residual
Mess
SMALL SMALL

229. +
Theory
Residual
Mess
CHALLENGEABLE! CHALLENGEABLE!

230. DIGITAL-NATIVE
BUSINESSES

231. LOAN APPROVAL
WORKFLOWS

232. We have 80+ work_lows

233. MANY WORKFLOWS
UNCONSISTENCIES
MAINTENANCE
TOO SEQUENTIAL
ANYONE LATE DELAYS
EVERYONE LATER

234. RAISE THE
WATERLINE

235. SIMILAR
STEPS
OVERALL
BUT NOT
ALWAYS
THERE
BY
DIFFERENT
TEAMS

236. MANY WORKFLOWS.
FEW RATIONALES.

237. MANY WORKFLOWS.
FEW RATIONALES.
TURNS OUT ALL
WORKFLOW ARE PRETTY
MUCH THE SAME

238. TEAM SEGMENTATION
DIR
FR UK CH SUN
(IT/SP/GR)
CLIENT COVERAGE
PARAMETERIZED WORKFLOW
➡ TEAM
chosen
by location

239. DELEGATION MECHANISM
DELEGATION
➡ TEAM
replaced
by delegation
➡ Steps by
same team
merged

240. DELEGATION MECHANISM
DELEGATION
Delegation by
amount
➡ optional
extra steps for
big amounts

241. Builder Pattern as a Virtual B.A.
Reasoning
To build
on-the-fly
concrete workflow

242. requirements
design
inductive
exploration
(speculative)
current
waterline
raise the
waterline!
agree with
experts
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

243. requirements
design new
waterline
MORE POTENTIAL FOR
SMARTER DESIGN
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

244. Going further…

245. What does the
workflow tries to
optimise for?

246. DISTURB
SENIOR
ROLES
LAST
MOST
LIKELY
TO FAIL
ASAP

247. Declare the preferences.
Let the tool find out the
workflow.
DISTURB
SENIOR
PEOPLE
LAST
MOST
LIKELY
TO FAIL
ASAP

248. Declare the preferences.
Let the tool find out the
workflow.
DISTURB
SENIOR
PEOPLE
LAST
MOST
LIKELY
TO FAIL
ASAP
WE CALL THAT
”SORTING”

249. Topological Sorting
http://flylib.com/books/en/2.300.1.142/1/

250. Topological Sorting
http://flylib.com/books/en/2.300.1.142/1/
ONLY DECLARE
PRE-REQUISITE
DEPENDENCIES

251. Topological Sorting
http://flylib.com/books/en/2.300.1.142/1/
LET THE TOOL
FIND OUT THE
WORKFLOW

252. Domain modelling
can literally express
human psychology.

253. requirements
design
inductive
exploration
(speculative)
current
waterline
raise the
waterline!
agree with
experts
Reverse-Engineering Again
(Progressing towards Higher Principles)

254. requirements
design new
waterline MORE POTENTIAL FOR
SMARTER DESIGN
Reverse-Engineering Investigation
(Progressing towards Higher Principles)

255. Going further…

256. When 80% of requests are
fully automated…

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

258. #NoWorkflow

259. UNDERLYING
TECHNOLOGYas-an-influence

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

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

262. RADICAL
RE-INVENTIONfrom first principles

263. What does the
workflow tries to
optimise for?

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

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

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

268. #before:
Engineering time is precious,
therefore GENeric indexes
#AFTER:
DEEP-LEARNING CAN REPLACE
HUMAN Engineering time

269. !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.

270. in closing

271. RAISE THE
WATERLINE

272. EXPECT
UNTOLD
REGULARITIES

273. PRACTICE TDD

274. PRACTICE
Domain-Driven
Design

275. Build theories,
not just lists of
business rules

277. LEARN TO
THINK FROM
FIRST
PRINCIPLES

279. Embrace
DIGITAL
Transformations

280. to
SOFTWARE-
AUGMENTED
BUSINESSES

281. @cyriux
Cyrille Martraire
Thanks!

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