Building a sustainable architecture

Transcript

1. Building a sustainable architecture
2. Marcelo Piva Software Engineer @ Nubank @mpivaa github.com/mpivaa instagram.com/mah.piva
3. Carolina Pascale Campos Software Engineer @ Nubank @CarolinaPascale github.com/carolpc instagram.com/carolpc books, coffee, running
4. motivation
6. smooth learning curve shipped code to production
7. almost no guidance
8. why?
10. 300+ engineers 300+ services 15M customers
12. patterns among services
13. functional programming tests △ hexagonal architecture ⬡
14. functional programming
15. fp is about pure functions
16. fp is about referential transparency
17. ��
18. Consistency Predictability Safety
19. we need to talk about side effects
20. not infecting your fp code with imperative code
21. limit the amount of imperative code
22. immutability vs mutability
23. pure functions + immutability
24. ✅ easier to reason ✅ easier to debug
25. persistent data structures (copy-on-write)
26. Structural Sharing A =
27. Structural Sharing A = B =
28. Structural Sharing
29. Structural Sharing A
30. Structural Sharing B
31. focus on what matters
32. Class Object Instance Inheritance Polymorphism Abstract Factory Builder Factory Method Object Pool Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Private Class Data Proxy Chain of responsibility Command Interpreter Iterator Mediator Memento Null Object Observer State
34. eliminate shared state so order does not matter
35. don't have to set up anything up
36. be as functional as you can
37. tests △
38. confidence safety
39. feedback
40. accuracy
41. speed
42. reliability
43. ✅ accuracy ✅ speed ✅ reliability
44. why highly testable code?
45. bonus: generative and property based testing
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: application
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. hexagonal architecture in FP is natural
61. push impure code to the boundaries
62. great discovery!
63. but, are we leveraring FP to its max?
64. services need to communicate
66. second layer with imperative code and side effects
67. why not imperative? harder to reason about harder to compose harder to test slower feedback
68. why not imperative? harder to reason about harder to compose harder to test slower feedback
69. why not imperative? (block! card datomic producer) ; =>
70. why not imperative? (defn block! [card datomic producer] (when (logic.card/can-block? card) (let [locked-card (logic.card/block card)] (datomic.card/update! blocked-card datomic) (producer.card/status-changed! blocked-card producer))))
71. why not imperative? harder to reason about harder to compose harder to test slower feedback
72. why not imperative? (defn block-all! [customer cards datomic producer] (doseq [card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
73. why not imperative? (defn block-all! [customer cards datomic producer] (doseq [card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
74. why not imperative? (defn block-all! [customer cards datomic producer] (doseq [card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
75. why not imperative? harder to reason about harder to compose harder to test slower feedback
76. why not imperative? mocks & integration tests
78. Unit Integration E2E
79. why not imperative? harder to reason about harder to compose harder to test slower feedback
81. ❌ pure functions ❌ tests ❌ maintainability
82. let's try another approach
83. declaring effects on the return of functions
84. decouple decisions from effects
85. decouple intent from execution
86. (block card) ; => [{:effects/datoms [...] ; :effects/messages [...]}]
87. data as first class citizens
88. declarative
89. atomic operations
90. Global dependencies
91. Global dependencies Dependency injection
92. Dependency rejection Global dependencies Dependency injection
93. (defn block [card] (if (logic.card/can-block? card) (let [blocked-card (logic.card/block card)] (-> e/empty-effects (effect.card/update blocked-card) (effect.card/status-changed blocked-card)))) e/empty-effects))
95. second layer without side effects
96. become more expressive
97. ✅ pure functions ✅ tests ✅ maintainability
98. Thanks! We're hiring! https://grnh.se/5fc5f7e51 @mpivaa github.com/mpivaa instagram.com/mah.piva