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