Building a sustainable codebase with FP - ElixirConfEU

As software engineers we are always trying to be more productive, to deliver better code, and to have a faster development feedback. In this talk, we’ll explore how functional programming, tests and hexagonal architecture can perform great together in order to support a maintainable codebase for hundreds of engineers and services. Diving deeper on how we can levarage hexagonal architecture with dependency rejection in order to decouple decisions from effects, resulting in a code that is easier to reason, compose and test. The codebase is not the only one that take advantages from that, but also the developers. It helps everyone feels more comfortable and engaged about maintaining good practices. This is already proven to work really well at Nubank, which is considered the best bank in Brazil according to Forbes.

Transcript

1. Building a sustainable architecture
2. Carolina Pascale Campos Software Engineer @ Nubank @CarolinaPascale github.com/carolpc instagram.com/carolpc books, coffee, running
3. motivation
4. smooth learning curve shipped code to production
5. almost no guidance
6. why?
7. Nubank
8. 500+ engineers 400+ services 40+ squads 3+ countries 25M customers
10. patterns among services
11. functional programming tests △ hexagonal architecture ⬡
12. functional programming
13. x y
14. fp is about pure functions
15. fp is about referential transparency
16. what about the impure functions?
17. we need to talk about side effects
18. pure function -> impure function
19. not infecting your fp code with imperative code
20. limit the amount of imperative code
21. immutability vs mutability
22. pure functions + immutability ✅ easier to reason ✅ easier to debug
23. focus on what matters
24. eliminate shared state so order does not matter
25. be as functional as you can
26. tests △
27. confidence safeness
28. live documentation
29. feedback
30. accuracy
31. speed
32. reliable feedback
33. e2e is a problem
34. ✅ accuracy ✅ speed ✅ reliability
35. how to design our code?
36. high maintainability low tech debt
37. maintainability is a long term concept
38. first attempt: hexagonal architecture
39. inner layer: domain model
40. second layer: application
41. third layer: IO
42. separates business logic from IO
43. tests in isolation with mocks and stubs
44. dependency injection
45. first discover
46. hard things in OOP can be easy in FP (tests)
47. boundaries
48. third layer: IO
49. isolation
50. isolation is the dual of encapsulation
51. hard to balance between both
52. not a problem in FP
53. hexagonal architecture in FP is natural
54. push impure code to the boundaries
55. good FP design is ports and adapters
56. great discovery!
57. but, are we levaraging FP to its max?
58. second layer with imperative code and side effects
59. why not imperative? harder to reason about harder to compose harder to test slower feedback
60. why not imperative? harder to reason about harder to compose harder to test slower feedback
61. why not imperative? block!(card, db producer) ; =>
62. why not imperative? def block!(card, db, producer) do if Logic.Card.can_block?(card) do blocked_card = Logic.Card.block(card) Datomic.Card.update!(blocked_card, db) Producer.Card.status_changed!(blocked_card, producer) end end
63. why not imperative? harder to reason about harder to compose harder to test slower feedback
64. why not imperative? def block_all!(customer, card, db, producer) do cards |> Enum.map(fn card -> block!(card, db, producer) end) cards_block_notify!(customer, producer) end
65. why not imperative? def block_all!(customer, card, db, producer) do cards |> Enum.map (fn card -> block!(card, db, producer) end) cards_block_notify!(customer, producer) end
66. why not imperative? def block_all!(customer, card, db, producer) do cards |> Enum.map (fn (card) -> block!(card, db, producer) end) cards_block_notify!(customer, producer) end
67. why not imperative? harder to reason about harder to compose harder to test slower feedback
68. why not imperative? Mocks & Integration Tests
70. why not imperative? harder to reason about harder to compose harder to test slower feedback
71. Unit Integration E2E
72. ❌ pure functions ❌ tests ❌ maintainability
73. let's try another approach
74. hexagonal architecture with dependency rejection
75. decouple decisions from effects
76. decouple intent from execution
77. (block card) ; => {datoms: [...] ; effects_messages: [...]}]
78. def block!(card) do if Logic.Card.can_block?(card) do blocked_card = Logic.Card.block(card) %{ datoms: [ Effect.Card.update(blocked_card)], messages: [ Effect.Card.status_changed(blocked_card)]} end end
79. easier to compose def block_all(customer, cards) do cards |> Enum.map(fn card -> block(card) end) |> Effect.Card.card_blocked_notify(customer) end
80. atomic operations
81. data as first class citizens
83. second layer without side effects
84. become more expressive
85. ✅ pure functions ✅ tests ✅ maintainability
86. Thanks! https://grnh.se/5fc5f7e51 @CarolinaPascale github.com/carolpc instagram.com/carolpc