Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Building a sustainable architecture
Search
Marcelo Piva
October 26, 2019
Programming
1
110
Building a sustainable architecture
Marcelo Piva
October 26, 2019
Tweet
Share
More Decks by Marcelo Piva
See All by Marcelo Piva
Maintaining consistency in distributed systems with an effect machine
mpivaa
1
270
Fun with Monads
mpivaa
2
190
Go Pure with ClojureScript
mpivaa
2
180
Other Decks in Programming
See All in Programming
「個人開発マネタイズ大全」が教えてくれたこと
bani24884
1
290
Go 1.24でジェネリックになった型エイリアスの紹介
syumai
2
300
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
9
1.5k
[JAWS DAYS 2025] 最近の DB の競合解決の仕組みが分かった気になってみた
maroon1st
0
170
Rubyと自由とAIと
yotii23
6
1.9k
Drawing Heighway’s Dragon- Recursive Function Rewrite- From Imperative Style in Pascal 64 To Functional Style in Scala 3
philipschwarz
PRO
0
150
コミュニティ駆動 AWS CDK ライブラリ「Open Constructs Library」 / community-cdk-library
gotok365
2
260
もう少しテストを書きたいんじゃ〜 #phpstudy
o0h
PRO
21
4.3k
Better Code Design in PHP
afilina
0
180
CloudRun, Spanner に対する負荷試験の反省と オブザーバビリティによるアプローチ
oyasumipants
1
170
CDKを使ったPagerDuty連携インフラのテンプレート化
shibuya_shogo
0
120
⚪⚪の⚪⚪をSwiftUIで再現す る
u503
0
120
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Six Lessons from altMBA
skipperchong
27
3.6k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
115
51k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Thoughts on Productivity
jonyablonski
69
4.5k
A designer walks into a library…
pauljervisheath
205
24k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
The Language of Interfaces
destraynor
156
24k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Transcript
Building a sustainable architecture
Marcelo Piva Software Engineer @ Nubank @mpivaa github.com/mpivaa instagram.com/mah.piva
Carolina Pascale Campos Software Engineer @ Nubank @CarolinaPascale github.com/carolpc instagram.com/carolpc
books, coffee, running
motivation
None
smooth learning curve shipped code to production
almost no guidance
why?
None
300+ engineers 300+ services 15M customers
None
patterns among services
functional programming tests △ hexagonal architecture ⬡
functional programming
fp is about pure functions
fp is about referential transparency
��
Consistency Predictability Safety
we need to talk about side effects
not infecting your fp code with imperative code
limit the amount of imperative code
immutability vs mutability
pure functions + immutability
✅ easier to reason ✅ easier to debug
persistent data structures (copy-on-write)
Structural Sharing A =
Structural Sharing A = B =
Structural Sharing
Structural Sharing A
Structural Sharing B
focus on what matters
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
None
eliminate shared state so order does not matter
don't have to set up anything up
be as functional as you can
tests △
confidence safety
feedback
accuracy
speed
reliability
✅ accuracy ✅ speed ✅ reliability
why highly testable code?
bonus: generative and property based testing
how to design our code?
high maintainability low tech debt
maintainability is a long term concept
first attempt: hexagonal architecture
inner layer: domain model
second layer: application
third layer: IO
separates business logic from IO
tests in isolation with mocks and stubs
dependency injection
first discover
hard things in OOP can be easy in FP (tests)
boundaries
third layer: IO
hexagonal architecture in FP is natural
push impure code to the boundaries
great discovery!
but, are we leveraring FP to its max?
services need to communicate
None
second layer with imperative code and side effects
why not imperative? harder to reason about harder to compose
harder to test slower feedback
why not imperative? harder to reason about harder to compose
harder to test slower feedback
why not imperative? (block! card datomic producer) ; =>
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))))
why not imperative? harder to reason about harder to compose
harder to test slower feedback
why not imperative? (defn block-all! [customer cards datomic producer] (doseq
[card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
why not imperative? (defn block-all! [customer cards datomic producer] (doseq
[card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
why not imperative? (defn block-all! [customer cards datomic producer] (doseq
[card cards] (block! card datomic producer)) (cards-blocked-notify! customer producer))
why not imperative? harder to reason about harder to compose
harder to test slower feedback
why not imperative? mocks & integration tests
None
Unit Integration E2E
why not imperative? harder to reason about harder to compose
harder to test slower feedback
None
❌ pure functions ❌ tests ❌ maintainability
let's try another approach
declaring effects on the return of functions
decouple decisions from effects
decouple intent from execution
(block card) ; => [{:effects/datoms [...] ; :effects/messages [...]}]
data as first class citizens
declarative
atomic operations
Global dependencies
Global dependencies Dependency injection
Dependency rejection Global dependencies Dependency injection
(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))
None
second layer without side effects
become more expressive
✅ pure functions ✅ tests ✅ maintainability
Thanks! We're hiring! https://grnh.se/5fc5f7e51 @mpivaa github.com/mpivaa instagram.com/mah.piva