$30 off During Our Annual Pro Sale. View Details »

Yavaconf_-_How_to_make_your_architecture_scream_with_functional_domain_modeling.pdf

 Yavaconf_-_How_to_make_your_architecture_scream_with_functional_domain_modeling.pdf

Bartłomiej Słota

September 28, 2022
Tweet

More Decks by Bartłomiej Słota

Other Decks in Programming

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