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
330
エキスパートRails基礎
20200803社内勉強会資料。
yokoto
August 03, 2020
Tweet
Share
More Decks by yokoto
See All by yokoto
ひとりメタプログラミングRuby勉強会
yokoto
0
130
LINEボットを作ってみよう
yokoto
0
39
Other Decks in Programming
See All in Programming
Kotlin Multiplatform at Stable and Beyond (Android Makers 2024)
zsmb
0
290
Git Lint
bkuhlmann
4
750
Micro Frontends for Java Microservices - Devnexus 2024
mraible
PRO
0
490
Site Reliability Engineering for GMO
pyama86
8
1k
VS Code をプロダクトにどう取り込むか
onomax
1
370
初心者のためのRubyKaigi入門/RubyKaigi Introduction
a_matsuda
2
800
Random\Randomizer クラスで日常のあれこれを解決しよう! / Random\Randomizer class solves familiar trouble
cocoeyes02
0
250
Elm 0.19.0 Changes
bkuhlmann
0
490
ONE WEDGE_company_guide
1wedge_one
0
490
try!Swift Tokyo 2024 参加報告 LT
akidon0000
1
220
"config" ってなんだ? / What is "config"?
okashoi
0
240
GitHub Copilotのススメ
marcy731
1
200
Featured
See All Featured
Side Projects
sachag
451
41k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
GraphQLの誤解/rethinking-graphql
sonatard
50
9.2k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
The Pragmatic Product Professional
lauravandoore
25
5.8k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
357
22k
Optimizing for Happiness
mojombo
370
69k
Into the Great Unknown - MozCon
thekraken
10
990
XXLCSS - How to scale CSS and keep your sanity
sugarenia
241
1.2M
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
A better future with KSS
kneath
231
16k
Designing Experiences People Love
moore
136
23k
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のアーキテクチャに関心を持って、 再利用性の高いコードを書けるようになりたい おわり