Building a sustainable architecture

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
11. 300+ engineers 300+ services 40+ squads 3+ countries 15M customers
13. patterns among services
14. tests △ hexagonal architecture ⬡
15. functional programming
16. x y
17. fp is about pure functions
18. fp is about referential transparency
19. what about the impure functions?
20. we need to talk about side effects
21. pure function -> impure function
22. not infecting your fp code with imperative code
23. limit the amount of imperative code
24. immutability vs mutability
25. pure functions + immutability ✅ easier to reason ✅ easier to debug
26. persistent data structures (copy-on-write)
28. persistent data structures (copy-on-write)
29. focus on what matters
30. eliminate shared state so order does not matter
31. don't have to set up anything up
32. be as functional as you can
33. △
34. confidence safeness
35. live documentation
36. feedback
37. accuracy
38. speed
39. reliable feedback
41. no more e2e
42. think only a little larger
43. contract tests
44. ✅ accuracy ✅ speed ✅ reliability
45. why highly testable code?
46. how to design our code?
47. high maintainability low tech debt
48. maintainability is a long term concept
49. first attempt: hexagonal architecture
50. inner layer: domain model
51. second layer: controllers
52. third layer: IO
53. separates business logic from IO
54. tests in isolation with mocks and stubs
55. dependency injection
56. first discover
57. hard things in OOP can be easy in FP (tests)
58. boundaries
59. third layer: IO
60. isolation
61. isolation is the dual of encapsulation
62. hard to balance between both
63. not a problem in FP
64. hexagonal architecture in FP is natural
65. push impure code to the boundaries
66. good FP design is ports and adapters
67. great discovery!
68. but, are we levaraging FP to its max?
69. controllers with imperative code and side effects
70. why not imperative? harder to reason about harder to compose harder to test slower feedback
71. why not imperative? harder to reason about harder to compose harder to test slower feedback
72. why not imperative? block(card, db, producer) ; =>
73. why not imperative? const block = (card, db, producer) => { if(canBlock(card)) { const blockedCard = logicCard.block(card); datomicCard.update(blockedCard, db); producerCard.statusChanged(blockedCard, producer) } }
74. why not imperative? harder to reason about harder to compose harder to test slower feedback
75. why not imperative? const blockAll = (customer, cards, db, producer) => { cards .map(card => block(card, db, producer)) cardsBlockNotify(customer, producer) }
76. why not imperative? const blockAll = (customer, cards, db, producer) => { cards .map(card => block(card, db, producer)) cardsBlockNotify(customer, producer) }
77. why not imperative? const blockAll = (customer, cards, db, producer) => { cards .map(card => block(card, db, producer)) cardsBlockNotify(customer, producer) }
78. why not imperative? harder to reason about harder to compose harder to test slower feedback
79. why not imperative? Mocks & Integration Tests
81. why not imperative? harder to reason about harder to compose harder to test slower feedback
82. Integration Unit E2E
83. Unit Integration E2E
84. ❌ pure functions ❌ tests ❌ maintainability
85. let's try another approach
86. hexagonal architecture with dependency rejection
87. decouple decisions from effects
88. decouple intent from execution
89. block(card) ; => {effectsDatoms: [...] ; effectsMessages: [...]}]
90. const block = (card) => { if(canBlock(card)) { const blockedCard = block(card); return { effectsDatoms: [effectsCard.update(blockedCard)], effectsMessages: [effectsCard.statusChanged(blockedCard)] }; } }
91. easier to compose const blockAll = (customer, cards) => { cards .map(card => block(card)) .map(effect => effectsCard.cardsBlockedNotify (effect, customer)) }
92. atomic operations
93. data as first class citizens
95. controllers without side effects
96. become more expressive
97. ✅ pure functions ✅ tests ✅ maintainability
98. Thanks! We're hiring! https://grnh.se/5fc5f7e51 @CarolinaPascale github.com/carolpc instagram.com/carolpc
99. References and further reading https://github.com/immutable-js/immutable-js https://blog.codeminer42.com/introduction-to-functional-programming-with-javascript-c06a2540a7c3 https://www.youtube.com/watch?v=e-5obm1G_FY https://youtu.be/BMUiFMZr7vk https://t.co/azaMSSAnpO?amp=1 https://www.youtube.com/watch?v=0if71HOyVjY https://m.youtube.com/watch?v=US8QG9I1XW0