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
iOSでSVG画像を扱う
kishikawakatsumi
0
130
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
200
『毎日の移動』を支えるGoバックエンド内製開発
yutautsugi
2
260
オープンソースソフトウェアへの解像度🔬
utam0k
16
3.1k
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
410
Devvox Belgium - Agentic AI Patterns
kdubois
1
130
Devoxx BE - Local Development in the AI Era
kdubois
0
130
フロントエンド開発のためのブラウザ組み込みAI入門
masashi
6
3.2k
組込みだけじゃない!TinyGo で始める無料クラウド開発入門
otakakot
1
330
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
180
他言語経験者が Golangci-lint を最初のコーディングメンターにした話 / How Golangci-lint Became My First Coding Mentor: A Story from a Polyglot Programmer
uma31
0
310
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
330
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
1.7k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
A designer walks into a library…
pauljervisheath
209
24k
Documentation Writing (for coders)
carmenintech
75
5.1k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.5k
Agile that works and the tools we love
rasmusluckow
331
21k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
Speed Design
sergeychernyshev
32
1.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Producing Creativity
orderedlist
PRO
347
40k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
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のアーキテクチャに関心を持って、 再利用性の高いコードを書けるようになりたい おわり