Domain-Driven Design (DDD) and Functional Programming (FP) have a lot of good things in common: DDD has borrowed many ideas from the FP community, and both share a common inspiration on established formalisms like maths. Even in non functional languages like Java or C#, this combined set of practices from DDD, OO and FP helps craft simple and powerful code that reads well, that is very easy to test, that composes well and that can somehow describe itself. We will have a closer look at some of these ideas, in the context of domain models inspired from real-world projects. From value objects and DSL to abstract algebra creatures like monoids and friends, we will show how all that translates into beautiful code that may influence your coding style!

1. Ur Domain Haz
Monoids?
Cyrille Martraire - @cyriux

2. "My first
encounter with FP
concepts was from
DDD"

3. A matter
of Taste
http://rosshirt.blogspot.fr/
The Code
Gourmet
(dedicated to @ziobrando)

4. FP

5. Passionate
developer
PARIS
Since 1999
@cyriux
Cyrille Martraire

6. Paris Software
Craftsmanship Community
http://www.meetup.com/paris-software-craftsmanship/

7. TDD
BDD
DDD
Legacy

8. WARNING
The following show features
no spectacular stunt, no live
coding, only trivial Java code.
You can re-create or re-enact
at home with no danger.

9. a bit personal

10. Adopted 2005
Still in love

11. ...

12. What do DDD & FP
have in common?

13. FP = ?

16. http://www.jaider.net/archives/609-intro-to-functional-programming/
PURE

17. No State
No War

19. So what do
DDD & FP
have in
common?

20. Value Objects................................................................................................. 19

21. Learn one
and get the other
one for FREE!

22. DDD
FP
(OO)

23. NICE
STYLEof code

24. DDD+FP
= ?

26. Example
PLZ?

27. MONOIDZ!

28. @cyriux

29. Closure
Associativity
Neutral Element

31. only 3
numbers in
programming

32. 0, 1, MANY

33. Monoid:
encapsulate
diversity inside

34. 0, 1, MANY
Neutral Element
Element
Operation

35. Battle against
complexity

36. Encapsulate
details (unit...)
→ simple again

37. For a given interface I
find myself doing
often 0, 1, Many
OO FTW!

38. 0, 1, MANY
NullObject
Implementation(s)
Composite

39. Identity Element
= NullObject
VatCalculation.NONE

40. Applied often:
→ scalable process
→ can grow to
very complex
complexity

41. Example
PLZ!

42. Numbers
int+int=int
(3+5)+2=3+(5+2)
0

43. Lists
(.)+(.,.)=(.,.,.)︎
(a︎)+(b︎,c)=(a︎, b)+(c)︎
()

44. Strings
"hello"+"world"
"cy"+"ri"+"lle"
""

45. look simplistic;
the key to very
complex behavior

46. The key to infinite
scalability!

47. The key to infinite
incremental
computing!

48. Hadoop x Storm

49. Composeability

50. Monoids ☛ reduce

51. Monoids ☛ domain

52. Monoids are
typical FP

53. FP: everything
is a value

54. Therefore:
Monoids are
values!

55. VALUE
OBJECTS

56. Immutable
Equals by value

57. Not Anemic

58. 18°C
+ 16°C
= 34°C

59. returns a new
instance
Change -> new instance

60. SIDE-EFFECT
-free
FUNCTIONS

61. Immutability
&
Side-effect-free
functions!

62. Value Object
A DDD pattern
to import FP-ish
values in OO
languages

63. “Functional-First” style

64. 90%
“Functional-First” style
Value Objects
(Ok, gut feeling, I did’nt measure)

65. Money

66. (25, EUR)
+
(30, EUR)
=
(55, EUR)

67. (25, EUR)
+
(30, USD)
=
exception

68. Money
amount
currency
add(Money): Money
<<ValueObject>>

70. Cashflows
(Payments)

71. (25, EUR, today)
+
(30, EUR, today)
=
(55, EUR, today)

72. (25, EUR, today)
+
(30, EUR, next day)
=
exception

73. CashFlow
amount
currency
date
add(CashFlow):CashFlow
<<ValueObject>>

74. CLOSUREof
OPERATION

75. Cashflows
Sequences

76. (10, EUR, 20/03)
(30, EUR, 21/03)
(25, EUR, 21/03)
(12, EUR, 22/03)
(10, EUR, 20/03)
(55, EUR, 21/03)
(12, EUR, 22/03)
+
=

77. Cashflow Sequence
+
Cashflow Sequence
=
Cashflow Sequence

78. Object
Arithmetics

79. This is how domain
experts THINK
about it
SAY
SKETCH

81. Ranges

82. [1, 3]
Union
[2, 4]
=
[1, 4]

83. [1, 3]
Union
[2, 4]
=
[1, 4] ][

84. Predicates

85. Filter
AND
Filter
=
Filter

86. Filter
AND
Filter
=
Filter
Always
True

87. Filter
OR
Filter
=
Filter

88. Filter
OR
Filter
=
Filter
Always
False

89. Grants

90. Read, Write, Execute
"most secure wins"
r + w = r
w + x = w

91. Configuration
Maps

92. Color BLUE
Enable True
Timeout 30 +
=
Color RED
Enable False
Timeout 25
Desk FX
Color RED
Enable True
Timeout 25
Desk FX
Default Desk-specific

93. Color BLUE
Enable True
Timeout 30 +
=
Color RED
Enable False
Timeout 25
Desk FX
Color RED
Enable True
Timeout 25
Desk FX
Default Desk-specific
overw
rite
logical OR
m
in

94. Color BLUE
Enable True
Timeout 30 +
=
Color RED
Enable False
Timeout 25
Desk FX
Color RED
Enable True
Timeout 25
Desk FX
Default Desk-specific
overw
rite
logical OR
m
in
Values are monoids too!

95. Color BLUE
Enable True
Timeout 30 +
=
Neutral Element
Color BLUE
Enable True
Timeout 30

96. Color BLUE
Enable True
Timeout 30 +
=
Color BLUE
Enable True
Timeout 30
Value Objects may be
*BIG* object trees!
(DOM)

98. Non-Linear Stuff
(average, std dev,
K-clustering,
barycenters...)

99. Average + Average
= WRONG

100. Average + Average
Not Composeable!

103. avg = sum / count
avg = sum / count

104. avg = sum / count
avg = sum / count
+

105. avg = sum / count
avg = sum / count
+ +

106. avg = sum / count
avg = sum / count
avg = sum / count
+
=
+
=

107. (sum, count)
(sum, count)
(sum, count)
+
=
Average

108. (sum, sum2, count)
(sum, sum2, count)
(sum, sum2, count)
+
=
Std deviation

109. Can model as a
monoid even non-
linear stuff!

111. MOAR
MATHS
PLZ!

112. Monoid several times...
toString(): String
union(MailingList): MailingList
intersection(MailingList): Mailing
nobody(): MailingList
everybody(): MailingList
MailingList

113. Space
Vectors

114. average temperature
= t1.add(t2)
.scale(1/2)

115. returns a new
instance
Change -> new instance

116. Space Vector
toCelsius(): Temperature
toFarenheit(): Temperature
add(Temperature): Temperature
scale(double): Temperature
Temperature

117. Why
is it useful?

118. (10, EUR, 20/03)
(30, EUR, 21/03)
(25, EUR, 21/03)
(12, EUR, 22/03)
(10, EUR, 20/03)
(55, EUR, 21/03)
(12, EUR, 22/03)
+
=

119. Cashflow Sequence
+
Cashflow Sequence
=
Cashflow Sequence

120. This is how domain
experts THINK
about it
SAY
SKETCH

121. DECLARATIVE
STYLE

122. Much less code
Much less bugs

124. // without monoids
PaymentsFees(...)
PaymentsFeesWithOptions(...)
PaymentsFeesWithInsuranceAndOptions(...)
PaymentsFeesWithInsurance(...)
NoFeesButInsurance(...)
...
// with monoids
fees(...) : Payments
options(...) : Payments
insurance(...) : Payments
Payments.add(Payments) : Payments

125. side-effect-
free
operation
Very easy to test
input output

126. Much less stuff to
learn

127. 1 interface
to rule them all

128. Cashflow Sequence
+
Cashflow Sequence
=
Cashflow Sequence

129. ESTABLISHED
FORMALISMS

130. Monoid/Vector
Spaces/Cyclic Group

131. Literature
Documented

132. @annotations
@Monoid()
intersection(MailingList): MailingList
@NeutralElement("intersection")
nobody(): MailingList
MailingList

133. LIVINGDOCUMENTATION

134. Signal to Noise ratio
http://www.flickr.com/photos/28471130@N07/2666802097

135. Signal to Noise Ratio
• SNR ≥ 80 %
• Signal (VO): CashFlow.multiply(),
CashFlowSequence.add(), .negate(),
truncate(),
Money.add(), .times(), .opposite(),
Fixing, FinancialProduct,
BankHolidays, ReferenceData
• Noise: CashFlowBuilder,
CompositeEngine, ProductFactory,
BankHolidaysDecorator

136. Write code that
tells the business
domain stories

137. @annotations
@Monoid()
intersection(MailingList): MailingList
@NeutralElement("intersection")
nobody(): MailingList
MailingList

138. Domain-Specific
@Monoid()
overlaping(MailingList): MailingList
@NeutralElement("overlaping")
nobody(): MailingList
MailingList

139. Value Objects have
domain-specific
flavors too:
Convention, Policy,
Status, Quantity,
Observation...

140. - Annotate domain-relevant classes
- Custom Doclet to export Excel-
formatted glossary of every domain
concept
Glossary from Code

141. Sent directly to end customers
Glossary from Code

142. SELF-
EXPLAINING
VALUES

143. WeWant:
Traceability
of processing

144. No worry!

145. Just enrich our
types

146. Just enrich our
types

147. Just enrich our
types
label field

148. Monad-ish
No logging needed
Each value stores
its history

149. http://stuartcook.files.wordpress.com/2010/11/happy-monkey.jpg

151. In Closing

152. Invest time:
Learn DDD, and get
free FP exposure

153. A paradox:
FP influence helps
craft better Object-
Oriented code!

154. Monoids
are good:
Eat Them!

155. LOOK 4 Ur
DOMAIN
MONOIDZ!

156. Also learn other
maths structures

157. Wikipedia is
your friend!

158. DDD+FP
=

159. http://wadler.blogspot.fr/2008/04/functional-programming-is-beautiful.html

160. Taste-Driven
Development
TDD

162. Questions? Did you try
similar things too?
Let’s discuss!
@cyriux

163. Follow me @cyriux
Slides: slideshare.net/cyriux
Blog: cyrille.martraire.com
In Paris? Join !

164. Merci