Yavaconf_-_How_to_make_your_architecture_scream_with_functional_domain_modeling.pdf

Transcript

1. @bartekslota How to make your architecture scream with functional domain modeling
2. Consultant/Trainer/Mentor @ Software Engineer Speaker Blogger Bartłomiej Słota @bartekslota bartslota.com bartlomiej.slota@gmail.com github.com/bslota linkedin.com/in/bslota
3. Electric bike lending
4. The common way - anemic model
5. The common way - fat service
6. The common way - the big ball of … (you name it)
7. The common way - the big ball of … (you name it) Primitive obsession
8. The common way - the big ball of … (you name it) Business rules’ leakage
9. The common way - the big ball of … (you name it) Cannonical model
10. The common way - the big ball of … (you name it) Communicating failures with exceptions
11. The common way - the big ball of … (you name it)
12. The common way - the big ball of … (you name it)
13. The common way - the big ball of … (you name it)
14. The common way - the big ball of … (you name it)
15. 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?
16. Functional programming
17. Which part is pure?
18. Where is the domain logic?
19. Moving the logic away
20. What’s the function? String, String, Integer, Customer -> Lending ???
21. What’s the function? String, String, Integer, Customer -> Lending VehicleId, StationId, ReservationDuration, Customer -> Lending
22. What’s the function? VehicleId, StationId, ReservationDuration, Customer -> Lending MakeReservationCommand -> Lending
23. Testability
24. Testability
25. Explicit dependencies MakeReservationCommand, IdSupplier, ClockSupplier -> Lending
26. Explicit dependencies MakeReservationCommand, IdSupplier, ClockSupplier -> Lending Currying IdSupplier -> ClockSupplier -> MakeReservationCommand -> Lending
27. Function Currying
28. Function Currying
29. Partial application
30. Handling results
31. Handling results MakeReservationCommand -> Result<MakeReservationFailure, Lending>
32. Handling results - representing failures MakeReservationCommand -> Result<MakeReservationFailure, Lending>
33. Handling results - client code
34. Chaingin results MakeReservationCommand -> Lending Lending -> Session MakeReservationCommand -> Result<MakeReservationFailure, Lending> VS Lending -> Session
35. Chaining results
36. Chaining results
37. Chaining results
38. Bind
39. Map
40. 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
41. Is it a bird? Is it a plane? Is it the twister?
42. Is it a bird? Is it a plane? Is it the twister? NO! It’s a monad!
43. Domain and codomain
44. Domain and codomain Lending, FinishLendingCommand -> Result<FinishingLendingFailure, Lending>
45. Domain and codomain Lending —> Lending Finished Pending Finished Pending
46. Domain and codomain Lending —> Lending Finished Pending Finished Pending
47. Domain and codomain PendingLending —> FinishedLending Pending Finished
48. Domain and codomain - the state pattern
49. Domain and codomain - the state pattern
50. Domain and codomain - the state pattern
51. Domain API vs use case API FinishLendingCommand -> Result<FinishLendingFailure, FinishedLending> FinishLendingCommand -> FinishedLending Vs
52. Workflows - onion architecture IO Domain IO Source: Scott Wlaschin, Domain Modeling Made Functional
53. 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
54. Predicate
55. Higher-order functions
56. Joining policies
57. Policies redefined
58. Policies redefined
59. Policies redefined
60. Policies redefined
61. Policies redefined
62. 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
63. Read more
64. Thank you! @bartekslota bartslota.com bartlomiej.slota@gmail.com github.com/bslota linkedin.com/in/bslota