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
430
エキスパートRails基礎
20200803社内勉強会資料。
yokoto
August 03, 2020
Tweet
Share
More Decks by yokoto
See All by yokoto
ひとりメタプログラミングRuby勉強会
yokoto
0
180
LINEボットを作ってみよう
yokoto
0
46
Other Decks in Programming
See All in Programming
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
360
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
890
XP, Testing and ninja testing
m_seki
3
240
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
5.6k
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
250
生成AI時代のコンポーネントライブラリの作り方
touyou
1
210
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
PipeCDのプラグイン化で目指すところ
warashi
1
270
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
130
RailsGirls IZUMO スポンサーLT
16bitidol
0
180
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
A2A プロトコルを試してみる
azukiazusa1
2
1.4k
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
The Cult of Friendly URLs
andyhume
79
6.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Scaling GitHub
holman
460
140k
Adopting Sorbet at Scale
ufuk
77
9.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Gamification - CAS2011
davidbonilla
81
5.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
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のアーキテクチャに関心を持って、 再利用性の高いコードを書けるようになりたい おわり