Slide 1

Slide 1 text

@bartekslota How to make your architecture scream with functional domain modeling

Slide 2

Slide 2 text

Consultant/Trainer/Mentor @ Software Engineer Speaker Blogger Bartłomiej Słota @bartekslota bartslota.com [email protected] github.com/bslota linkedin.com/in/bslota

Slide 3

Slide 3 text

Electric bike lending

Slide 4

Slide 4 text

The common way - anemic model

Slide 5

Slide 5 text

The common way - fat service

Slide 6

Slide 6 text

The common way - the big ball of … (you name it)

Slide 7

Slide 7 text

The common way - the big ball of … (you name it) Primitive obsession

Slide 8

Slide 8 text

The common way - the big ball of … (you name it) Business rules’ leakage

Slide 9

Slide 9 text

The common way - the big ball of … (you name it) Cannonical model

Slide 10

Slide 10 text

The common way - the big ball of … (you name it) Communicating failures with exceptions

Slide 11

Slide 11 text

The common way - the big ball of … (you name it)

Slide 12

Slide 12 text

The common way - the big ball of … (you name it)

Slide 13

Slide 13 text

The common way - the big ball of … (you name it)

Slide 14

Slide 14 text

The common way - the big ball of … (you name it)

Slide 15

Slide 15 text

Questions •How much information do we get from looking at the code?
 •What is the di ff erence between stationId and customerId? Should they be equal when they have the same values?
 •Is Lending always a lending? Or maybe it can be just a reservation that is never used? Do I get this information from the Lending class?
 •Does Lending class tell me what can I do with the reservation?
 •Does Lending class tell me what does it mean that the lending was fi nished?
 •Is extending reservation for more than 5 minutes really an exceptional situation?

Slide 16

Slide 16 text

Functional programming

Slide 17

Slide 17 text

Which part is pure?

Slide 18

Slide 18 text

Where is the domain logic?

Slide 19

Slide 19 text

Moving the logic away

Slide 20

Slide 20 text

What’s the function? String, String, Integer, Customer -> Lending ???

Slide 21

Slide 21 text

What’s the function? String, String, Integer, Customer -> Lending VehicleId, StationId, ReservationDuration, Customer -> Lending

Slide 22

Slide 22 text

What’s the function? VehicleId, StationId, ReservationDuration, Customer -> Lending MakeReservationCommand -> Lending

Slide 23

Slide 23 text

Testability

Slide 24

Slide 24 text

Testability

Slide 25

Slide 25 text

Explicit dependencies MakeReservationCommand, IdSupplier, ClockSupplier -> Lending

Slide 26

Slide 26 text

Explicit dependencies MakeReservationCommand, IdSupplier, ClockSupplier -> Lending Currying IdSupplier -> ClockSupplier -> MakeReservationCommand -> Lending

Slide 27

Slide 27 text

Function Currying

Slide 28

Slide 28 text

Function Currying

Slide 29

Slide 29 text

Partial application

Slide 30

Slide 30 text

Handling results

Slide 31

Slide 31 text

Handling results MakeReservationCommand -> Result

Slide 32

Slide 32 text

Handling results - representing failures MakeReservationCommand -> Result

Slide 33

Slide 33 text

Handling results - client code

Slide 34

Slide 34 text

Chaingin results MakeReservationCommand -> Lending Lending -> Session MakeReservationCommand -> Result VS Lending -> Session

Slide 35

Slide 35 text

Chaining results

Slide 36

Slide 36 text

Chaining results

Slide 37

Slide 37 text

Chaining results

Slide 38

Slide 38 text

Bind

Slide 39

Slide 39 text

Map

Slide 40

Slide 40 text

A type that wraps another type That has a function wrapping the original value And has a function that unfolds the original value, applies some other function, and creates the new wrapped value of the same type

Slide 41

Slide 41 text

Is it a bird? Is it a plane? Is it the twister?

Slide 42

Slide 42 text

Is it a bird? Is it a plane? Is it the twister? NO! It’s a monad!

Slide 43

Slide 43 text

Domain and codomain

Slide 44

Slide 44 text

Domain and codomain Lending, FinishLendingCommand -> Result

Slide 45

Slide 45 text

Domain and codomain Lending —> Lending Finished Pending Finished Pending

Slide 46

Slide 46 text

Domain and codomain Lending —> Lending Finished Pending Finished Pending

Slide 47

Slide 47 text

Domain and codomain PendingLending —> FinishedLending Pending Finished

Slide 48

Slide 48 text

Domain and codomain - the state pattern

Slide 49

Slide 49 text

Domain and codomain - the state pattern

Slide 50

Slide 50 text

Domain and codomain - the state pattern

Slide 51

Slide 51 text

Domain API vs use case API FinishLendingCommand -> Result FinishLendingCommand -> FinishedLending Vs

Slide 52

Slide 52 text

Workflows - onion architecture IO Domain IO Source: Scott Wlaschin, Domain Modeling Made Functional

Slide 53

Slide 53 text

Meta model of the logic Stable logic Logic closure The choice of the closure - Stable process - Small susceptibility to change - Many variants - Many details - Dynamically de fi ned Impl1 Impl2 Impl3

Slide 54

Slide 54 text

Predicate

Slide 55

Slide 55 text

Higher-order functions

Slide 56

Slide 56 text

Joining policies

Slide 57

Slide 57 text

Policies redefined

Slide 58

Slide 58 text

Policies redefined

Slide 59

Slide 59 text

Policies redefined

Slide 60

Slide 60 text

Policies redefined

Slide 61

Slide 61 text

Policies redefined

Slide 62

Slide 62 text

How to make your architecture scream? •Model your code thinking of functions and work fl ows instead of state •Have referential transparency in mind •Model your class hierarchies so that they correspond to the true domain and codomain of your business function •Avoid side e ff ects like exceptions and mutability •Keep your domain pure - move IO to the outside layer of your onion •Use monadic types to improve readability and robustness

Slide 63

Slide 63 text

Read more

Slide 64

Slide 64 text

Thank you! @bartekslota bartslota.com [email protected] github.com/bslota linkedin.com/in/bslota