This document discusses domain typing in Ruby through the lens of functional programming and domain-driven design. It introduces concepts like defining types as sets of possible values, using types to improve safety and intellectual manageability, and modeling domains and behavior through state machines and explicit state transitions. While typing is not native to Ruby, libraries like dry-types, dry-struct, and dry-logic make it possible to integrate these approaches and reap their benefits, moving Ruby code in a more functional direction.

1. Domain Typing
in Ruby

2. HELLO!
I am Sergiy Kukunin
Feel free to follow me at @sergey_kukunin
2

3. Plan
Setting context of the problem
A lot of ruby code (small snippets)
Conclusions
Questions and Answers
3

4. This talk contains
functional programming
4

5. This talk contains
domain-driven design
5

6. I was on RubyC 2017 6

7. Two values
of software
7

8. “I now suggest that we confine ourselves
to the design and implementation of
intellectually manageable programs
© Edsger W. Dijkstra, 1972
88

9. Intellectually
manageable
programs
9

10. Safety

11. “How to shoot yourself in the foot using Perl
You shoot yourself in the foot, but
nobody can understand how you did it.
Six months later, neither can you.
1111

12. Safety improves
intellectual
manageability
12

13. Safety matters
▰Assembler is hard to manage
▰Goto statements are banned because of
complexity
▰Eval is almost banned
13

14. Typing

15. Typing aims for
better safety
15

16. I ain’t gonna make
Java in Ruby
16

17. Disclaimer
17
Inspired by F#
https://fsharpforfunandprofit.com/ddd/

18. Functional programming conquers
▰Avoid (global) mutable state
▰Composability over Inheritance
▰Service objects and data bags
▰Lambdas
18

19. How it looks in F#
19
module CardGame =
type Suit = Club | Diamond | Spade | Heart
type Rank = Two | Three | Four | Five | Six | Seven | Eight
| Nine | Ten | Jack | Queen | King | Ace
type Card = Suit * Rank
type Hand = Card list
type Deck = Card list
type Player = {Name:string; Hand:Hand}
type Game = {Deck:Deck; Players: Player list}
type Deal = Deck -> (Deck * Card)
type PickupCard = (Hand * Card) -> Hand

20. 20

21. 21

22. 22

23. 23

24. 24

25. 25

26. Types Algebra
26
In theory

27. Type is a set of possible values
type Suit = Club | Diamond | Spade | Heart
type Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine
| Ten | Jack | Queen | King | Ace
type Card = Suit * Rank
27

28. 28

29. 29

30. 30

31. 31

32. 32

33. 33

34. 34

35. 35

36. In F# it’s simple
36

37. 37

38. Let’s go deeper
38

39. 39

40. “A contact must have at least one contact information”
Implies
▰email address only, or
▰postal address only, or
▰both email and postal addresses
40

41. 41

42. Meanwhile in F#
42

43. “A contact must have at least one contact information”
43
Is it really what business wants?

44. 44

45. States and
Transitions
45

46. States and transitions for shopping cart
46
EmptyCart ActiveCart PaidCart
Pay
Add ItemAdd Item
Remove ItemRemove Item

47. 47

48. What’s about
behaviour?

49. Object-oriented style
49

50. Functional style
50

51. 51

52. Why is that cool?
Each state has own set of data
All states are explicitly documented
All transitions are explicitly documented
It’s safe because it makes you think about any
combination
52

53. Caveats
Non-native support
Indistinguishable types
Requires mindshift
Complex persistence aspect
In-mature approach in Ruby
53

54. ● dry-types
● dry-struct
● dry-logic
It’s possible thankfully to dry-rb
http://dry-rb.org/

55. Further reading
▰Functional programming
▰Domain-driven design
▰Typing Algebra
▰dry-rb and rom-rb toolkits
▰F# as friendly functional language
55

56. 56
THANKS!
Any questions?
You can find me at
@sergey_kukunin & sergey.kukunin@gmail.com