Clean Architecture on Rails - RubyConf Brasil 2015

Transcript

1. CLEAN ARCHITECTURE ON RAILS
3. It’s impressive how this talk spread like wild fire!
4. CHAPTER I What is Clean Architecture?
5. but, who am I?
6. Fabiano Beselga CTO magnetis.com.br WRITER medium.com/@fbzga TWITTER @fbzga
7. bit.ly/clean-rails
8. CHAPTER I What is Clean Architecture?
9. the PROBLEM
11. your top level structure is screaming the web FRAMEWORK
12. The web is a delivery mechanism
13. the web is a COMMODITY
14. yet it DOMINATES your code
15. image you’ve just joined a PROJECT
18. what makes a GOOD architecture?
19. it is not about frameworks and tools
20. IVAR JACOBSON
21. business rules INTERACTORS (aka use cases)
22. domain model ENTITIES
23. communication interfaces BOUNDARIES
24. diagrams: Robert C Martin
30. What about MVC?
31. MVC as a Web architecture
32. this is NOT WHAT I MEANT
33. WEB FRAMEWORK APP
34. CHAPTER II HOW to use it with Rails?
35. BRAAVOS
37. WE ARE OPENING A BANK! WE NEED TO HIRE A GREAT DEVELOPER!
39. WHAT ABOUT THIS ONE?
43. HIRED!
44. first day at WORK
45. THE SYSTEM MUST TRANSFER MONEY BETWEEN THE FAMILIES ACCOUNTS
46. OK! ANY EXCEPTION COURSES?
47. WHEN THERE ISN’T ENOUGH MONEY TO TRANSFER.
48. that’s easy, I can do it in 7 STEPS!
49. GREAT! YOU HAVE 10 MINUTES!
50. challenge accepted!
51. 1 create the PROJECT
52. rails new braavos
53. mkdir core
54. module Core end core.rb
55. 2 define BOUNDARIES
56. README Driven Development
57. Usage Transfer money Core.transfer_money(amount: 10_000, source_account_id: 1, destination_account_id: 2) README => true # when transfer successful => false # when not enough balance
58. 3 define behaviour Driven Development
59. context 'enough money to transfer' do it 'responds true' do expect(transfer).to be true end it 'debits the source account' do expect{ transfer }.to change{ source_account_balance }.by(- amount) end it 'credits the destination account' do expect{ transfer }.to change{ destination_account_balance }.by(amount) end end PRIMARY course
60. context 'not enough money to transfer' do it 'cancels the transfer and responds false' do expect(transfer).to be false end it 'does not change the accounts balance' do expect{ transfer }.to_not change{ source_account_balance } expect{ transfer }.to_not change{ destination_account_balance } end end EXCEPTION COURSE
61. FFF
62. define DATA MODEL 4
63. CAN YOU TELL ME A LITTLE MORE ABOUT THE DOMAIN?
64. EACH FAMILY HAS AN ACCOUNT. EACH ACCOUNT HAS A HISTORY OF TRADES MADE.
65. rails g model account name rails g model trade account:references amount:decimal date:date
66. trades debit: -1000 credit: +1000
67. the ENTRY POINT 5
68. module Core class << self delegate :transfer_money, to: TransferMoney end end core.rb
69. the USE CASE 6 Image: HENRY HEMMING
70. module Core class TransferMoney def self.transfer_money(source_account_id:, destination_account_id:, amount:) balance = Core.get_balance(account_id: source_account_id) return false if balance < amount ActiveRecord::Base.transaction do Trade.create!(account_id: source_account_id, amount: -amount) Trade.create!(account_id: destination_account_id, amount: amount) end end end end core/transfer_money.rb
71. …
73. REFACTOR!
74. module Core class << self delegate :transfer_money, to: TransferMoney end end core.rb before
75. CAZE DSL to elegantly declare use cases
76. Gemfile gem 'caze'
77. module Core include Caze has_use_case :transfer_money, TransferMoney end core.rb AFTER
78. module Core include Caze has_use_case :transfer_money, TransferMoney, transactional: true end core.rb AFTER
79. g github.com/magne/s/caze
80. BREAKING NEWS! 
 WE HAVE MONEY TO HIRE AGAIN!
81. WHAT ABOUT THIS SNOW?
82. WHAT?
85. Usage Transfer money Core.transfer_money(amount: 10_000, source_account_id: 1, destination_account_id: 2) README => true # when transfer successful => false # when not enough balance
87. expose it to the web 7
88. let’s call it on a CONTROLLER
89. class TransferMoneyController < ApplicationController before_action :load_balance def create if Core.transfer_money(source_account_id: source_account_id, destination_account_id: destination_account_id, amount: amount) redirect_to new_transfer_money_path else flash[:error] = 'Not enough money on the source account' render :new end end private def load_balance @balance = Core.get_balance(account_id: current_account_id) end end
91. bit.ly/braavos
92. what just happened?
93. Core represents WHAT THE SYSTEM Does CHANGES
94. core/ get_balance.rb transfer_money.rb BEHAVIOUR CHANGES
95. the models represent WHAT THE SYSTEM IS STABLE
96. app/ models/ account.rb trade.rb DATA STABLE
97. a key, longstanding hallmark of a good program is that it separates what is stable from what changes in the interest of good maintenance. - Trygve Reenskaug
98. Core represents WHAT THE SYSTEM Does CHANGES
99. the models represent WHAT THE SYSTEM IS STABLE
100. Models Core Rails delivery mechanism behaviour MODULE data
101. the ALTERNATIVES
102. Models Core Rails delivery mechanism behaviour RAILS ENGINE
103. The database is a detail
104. Isolate it!
105. Models Core Rails delivery mechanism behaviour gem rails engine data
106. Core Web Models UI DB Controllers Views
107. but what makes a GOOD architecture?
108. CLEAN ARCHITECTURE HEXAGONAL ARCHITECTURE DOMAIN DRIVEN DESIGN DATA CONTEXT INTERACTION TRAILBLAZER
109. all these architectures have SIMILAR OBJECTIVES
110. what about real life?
111. magnetis.com.br
112. ~ 4 years old codebase
113. experimenting with clean architecture ~ 2 years
115. the first seeds magnetis core
116. a module for each DOMAIN CONCEPT
117. we have a module for investments recommendation Advisor
118. Advisor.recommend_investments(params)
120. we have a module for accounting Accountant
122. magnetis/ domain/ accountant/ advisor/
123. BOUNDED CONTEXTs Advisor Accountant Order Manager Account Manager Trader Pricing Backtesting
124. why not MICROSERVICES?
125. we also use the Rails WAY
126. FINAL CHAPTER when to use it?
127. YOUR PRODUCT
128. core business your product rails way clean architecture
129. Eric Evans Don’t try yo apply DDD to everything. Draw a context map and decide on where you will make a push for DDD and where you will not .
130. THE distance from the view
131. the domain logic is close to the view Rails way
132. the domain logic is far from the view Clean architecture
133. TIMING
134. image: Kent Beck
135. Lessons learned
136. no good
137. Over-engineering when the domain logic is close to the view
138. getting out of the rails conventions may be hard
139. the cool STUFF
140. defer decisions until the last responsible moment
141. it SCREAMS BEHAVIOR
142. decoupled business rules
143. tests RUNNING FASTER!
144. what makes a GOOD architecture?
145. Architecture is about Intent
146. Intent = what the SYSTEM DOES
147. reflect THE USER’S MENTAL MODEL in your architecture
148. domain as a 1st class citizen
149. ONE MORE THING…
152. we are hiring fabiano@magne/s.com.br magne/s.com.br/dev
153. Developer #1 Developer #2 The Boss The Mastermind Tio Roberto Domain Father Advisor Presenter CAST TYRION LANNISTER Jon SNOW SHERKLOCKS’ BROTHER IVAR JACOBSON UNCLE BOB ERIC EVANS ROBERT DUVAL FABIANO BESELGA by @fbzga