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
エキスパートRails基礎
Search
yokoto
August 03, 2020
Programming
1
460
エキスパートRails基礎
20200803社内勉強会資料。
yokoto
August 03, 2020
Tweet
Share
More Decks by yokoto
See All by yokoto
ひとりメタプログラミングRuby勉強会
yokoto
0
180
LINEボットを作ってみよう
yokoto
0
47
Other Decks in Programming
See All in Programming
Devoxx BE - Local Development in the AI Era
kdubois
0
120
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
960
ポスターセッション: 「まっすぐ行って、右!」って言ってラズパイカーを動かしたい 〜生成AI × Raspberry Pi Pico × Gradioの試作メモ〜
komofr
0
1.2k
デミカツ切り抜きで面倒くさいことはPythonにやらせよう
aokswork3
0
220
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
2
630
Conquering Massive Traffic Spikes in Ruby Applications with Pitchfork
riseshia
0
160
CSC509 Lecture 02
javiergs
PRO
0
410
止められない医療アプリ、そっと Swift 6 へ
medley
1
140
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
210
技術的負債の正体を知って向き合う / Facing Technical Debt
irof
0
130
エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit
minodriven
24
12k
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1.1k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
Thoughts on Productivity
jonyablonski
70
4.9k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Documentation Writing (for coders)
carmenintech
75
5k
Visualization
eitanlees
148
16k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Designing for humans not robots
tammielis
254
26k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Making Projects Easy
brettharned
119
6.4k
Embracing the Ebb and Flow
colly
88
4.8k
Transcript
エキスパートRails基礎 2020/08/03 横田 俊博
パーフェクトRails増補改訂版が 発売されました。
None
None
「Skinny Controller, Fat Model」
「Skinny Controller, Fat Model」 限界
> アプリケーションが対象とする問題領域が複雑に なると、この設計原則だけでは立ち行かなくなって しまいます。 > Railsのモデルはその構造上、単体ではうまく表 現できない種類のロジックがいくつかあり、問題の 複雑さが増すとこれらが目立つようになるからで す。 パーフェクトRuby
on Rails p.460
https://techracho.bpsinc.jp/hachi8833/2013_11_19/14738 2012年
- 中規模Web開発のためのMVC分割とレイヤアーキテクチャ - てめえらのRailsはオブジェクト指向じゃねえ!まずはCallbackクラス、Validatorク ラスを活用しろ! - 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止め てくれ - Railsの太ったモデルをダイエットさせる方法について
- Fat Modelの倒し方 / how to deal with fat model - 3年以上かけて培ったRails開発のコツ集大成(翻訳)|TechRacho(テックラッ チョ)〜エンジニアの「?」を「!」に 2013年~
2020年
11-1. アーキテクチャパターンから見るRails
Railsの考え方を深く理解するための、 アプリケーションとアーキテクチャに関する用語 1. ドメイン - アプリケーションが対象とする問題領域 - 例)ユーザー、求人、物件、etc 2. ドメインモデル
- ドメインの構成概念に関連する属性と振る舞いを持ったオブジェクト - 例)User(id:, name:, email:, telephone:) 3. アクティブレコード - ドメインモデルとデータベースを対応付けるライブラリ - テーブル => クラス - レコード => クラスのインスタンス - カラム => インスタンスの属性
アクティブレコードのメリットとデメリット - メリット - データベースのテーブルとクラスが直接対応しているため、単純で理解しやす い。 - デメリット - 構造上、単体では複雑なドメインロジックを表現しきれない
=> Fat Model
単一責任の原則 - オブジェクト指向設計のための5つの設計原則である『SOLID』のS - Single Responsibility Principle(単一責任の原則) - Open-Closed Principle(オープン・クローズドの原則)
- Liskov Substitution Principle(リスコフの置換原則) - Interface Segregation Principle(インターフェース分離の原則) - Dependency Inversion Principle(依存関係逆転の原則) - クラスやメソッドを1文で説明できる - クラス(オブジェクト)が担う責任は1つに限定すべきである - クラスを変更するときの理由付けは、1つしかあってはならない - 1つのクラスは1つの仕事しかしない
11-2. 値オブジェクト
ドメインに固有の、「値」に関するロジック
> 一見問題がないように見えますが、電話番号や他の値に関す るロジックを実装していくと、すぐにUserモデルが肥大化していき ます。 パーフェクトRuby on Rails p.464
> PhoneNumberという値オブジェクトを導入することで、電話番 号に関するロジックがUserモデルから分離されました。
> これで、電話番号に関するロジックが増えたとしても、Userモデ ルが不要に肥大化することはありません。 > また、電話番号に関するロジックをどこに実装すべきかが明ら かになり、そのロジックを複数のモデルの間で簡単に再利用でき るようになりました。 パーフェクトRuby on Rails
p.465
11-3. サービスオブジェクト
> Railsでアプリケーションを開発していると、モデルに実装すると 不自然なドメインロジックが出てくることがあります。 > 代表的な例が、複数のオブジェクトを組み合わせて表現するロ ジックです。 > サービスオブジェクトは、このようなロジックを独立したオブジェ クトとして定義したものです。 パーフェクトRuby
on Rails p.466
> balance(残高)という属性を持つBankAccount(口座残高)モデルを例に説明していきます。 > Moneyという値オブジェクトを導入して、これを口座残高の表現に用いると、次のようになります。
> 口座間の送金ロジックを実装したいとしましょう。説明を簡単に するため、送金ロジックは資金の引き出しと預入に酔ってのみ構 成されるものとします。送金元口座、送金先口座、送金資金をそ れぞれfrom、to、moneyとすると、次のように記述できます。
> このロジックをどこに実装すべきかを考えてみましょう。 > 複数の口座オブジェクトの状態を更新していることから、 BankAccountモデルのインスタンスメソッドとして実装するのは 不自然です。 > クラスメソッドとして実装した方がまだ自然ではありますが、この ような複数のオブジェクトを操作するロジックを実装していくと、す ぐにBankAccountモデルが肥大化していきます。このようなとき、
サービスオブジェクトを導入すると良いでしょう。 パーフェクトRuby on Rails p.468
app/services/transfer_money_between_bank_accounts_service.rb > このようなロジックを適宜サービスオブジェクトに実装していけば、BankAccountモデルが 不要に肥大化することもありません。 > サービスオブジェクトは「状態を持たない」ことに注意してください。 > callメソッドはデータベースの内容というグローバルな状態は更新しているものの、インス タンス変数をはじめとした自身の状態は更新していません。
サービスオブジェクト導入時のポイント - モデルに実装すべきロジックまで実装しない - オブジェクトの属性の値を直接参照・更新しているような箇所があれば、その 操作を対応するモデルのインスタンスメソッドとして定義すべきではないか考え る。 - イベント(create, destroyなど)の見落としがないか確認する
- ロジックではなくイベントに注目して実装する場合、サービスオブジェクトではな くイベントを表現するモデルを導入する。 - サービスオブジェクトを実装するクラスの名前は、ある1つのドメインロジックを指す ものにし、このロジックを実行するためのクラスメソッド を1つだけ公開する - サービスオブジェクトを肥大化させないようにする - 例)callメソッド
PORO(Plain Old Ruby Object) - ActiveRecordを継承しないふつうのオブジェクトのこと - services/配下に作成するサービスオブジェクトもPOROと言えるが、models/ 配下にPOROを作成するルールの現場もあるっぽい -
Railsの太ったモデルをダイエットさせる方法について - 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作る のは止めてくれ - ドメインモデルを記述するディレクトリとして、models/、services/以外にfinder/、 validator.、callback/、parameter/などを作成する現場もあるっぽい - Railsでやってしまいがちな保守性を下げてしまうコードとその解決策
おまけ: Fat Viewについて - Helperを使うのをやめてDecoratorを使ってみる - Presenter(Decorator) - Railsでは、あるモデルが持つ属性やロジックを利用して、表示に関するロジックを実装する オブジェクトのことを指す
Railsのアーキテクチャに関心を持って、 再利用性の高いコードを書けるようになりたい おわり