Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/Aft...
Search
Junichi Kobayashi
November 12, 2024
Programming
5
2.2k
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night
After Kaigi on Rails 2024 LT Night での発表資料です。
Junichi Kobayashi
November 12, 2024
Tweet
Share
More Decks by Junichi Kobayashi
See All by Junichi Kobayashi
LR で JSON パーサーを作る / Coding LR JSON Parser
junk0612
2
750
「ナントカLR」を整理する / Clarifying LR Algorithms
junk0612
1
440
From LALR to IELR: A Lrama's Next Step
junk0612
2
3.7k
RubyConf Taiwan / Understanding Parser Generators surrounding Ruby with Contributing Lrama
junk0612
2
5.4k
LL法とLR法の違いは?調べてみた!-完全版-/Comparing LL and LR parse algorithm -EX Edition-
junk0612
0
600
ESM Super LT/Comparing LL and LR parse algorithm
junk0612
1
120
Lrama へのコントリビューションを通して学ぶ Ruby のパーサジェネレータ事情
junk0612
4
5.5k
ソフトウェア開発とコミュニケーション / Communication in Software Development
junk0612
0
1.2k
アジャイルという「マインドセット」 / Mindset named Agile
junk0612
0
930
Other Decks in Programming
See All in Programming
TypeScript でバックもやるって実際どう? 実運用で困ったこと3選
yuichiro_serita
17
7.5k
イマのCSSでできる インタラクション最前線 + CSS最新情報
clockmaker
5
3.8k
大規模サイトリビルドの現場から:成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024
techtekt
0
210
距離関数を極める! / SESSIONS 2024
gam0022
0
370
Serverless苦闘史
mosh_inc
0
140
flutterkaigi_2024.pdf
kyoheig3
0
450
Cursorでアプリケーションの追加開発や保守をどこまでできるか試したら得るものが多かった話
drumnistnakano
0
260
PaaSとSaaSの境目で信頼性と開発速度を両立する 〜TROCCO®︎のこれまでとこれから〜
gtnao
6
6.1k
初めてDefinitelyTypedにPRを出した話
syumai
0
480
Develop iOS apps with Neovim / vimconf_2024
uhooi
1
280
似たもの同士のPerlとPHP
uzulla
1
110
Seamless Flutter Native Integration: FFI & Pigeon - Dreamwalker (JaichangPark / 박제창) @FlutterKaigi2024
itsmedreamwalker
0
100
Featured
See All Featured
Thoughts on Productivity
jonyablonski
67
4.3k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
Documentation Writing (for coders)
carmenintech
65
4.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
How to Ace a Technical Interview
jacobian
276
23k
Faster Mobile Websites
deanohume
305
30k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Transcript
「今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって……」 After Kaigi on Rails 2024 LT Night
株式会社タイミー様 東京本社 2024/11/12(火) 小林 純一 (@junk0612) 株式会社永和システムマネジメント アジャイル事業部 Sponsor Talk
小林 純一 • X: @junk0612 • GitHub: @junk0612 • 永和システムマネジメント
◦ Rails エンジニア ◦ 構文解析器研究部員 • Lrama のコミッター • 趣味 ◦ パーサー ◦ 音楽ゲーム ◦ ボードゲーム ◦ 俳句
Kaigi on Rails お疲れ様でした!
None
今回の担当 • Beer 🍻 • Dora 🔔
None
None
提 供 情報化技術を通じて社会と共生する
2024/09/07
None
None
今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612
今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612 えっ何、app/services の話? @onk オレ、app/services にはちょっとうるさいよw @joker1007
app/services とかもあって…… @junk0612 えっ何、app/services の話? @onk オレ、app/services にはちょっとうるさいよw @joker1007 実際、app/services
ってちゃんと運用されること 少なくないですか? だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね? 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど @junk0612
いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら
ないで models 配下に直接置いちゃったほうがいい。 @onk 実際、app/services ってちゃんと運用されること 少なくないですか? だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね? 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど。 @junk0612
いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら
ないで models 配下に直接置いちゃったほうがいい。 @onk 結局のところ、rails new した時に作られるディレクトリ 以外に新しいディレクトリを作ろうとするのは Rails Way に乗らないことなんで基本的にやらないほうがいい んですよ。Form オブジェクトだったら許せる。複雑なビ ジネスロジックを扱いたいときっていうのはどうしてもあ るんで、それをモデルに書いて fat になるくらいだったら Form オブジェクトを models 配下に直接置くほうがい いですよ。 @joker1007
app/services が切られる理由(1) • サービスレイヤーに属するクラスの置き場所 ◦ 出典は PofEAA ◦ app/models 配下のクラスを
「ドメインモデル」として扱う ◦ ドメインモデルを操作して、処理を行う層 https://martinfowler.com/eaaCatalog/serviceLayer.html
app/services が切られる理由(2) • サービスオブジェクトの置き場所 ◦ Rails でのデザインパターンの1種 ◦ 複数のモデルにまたがったり 条件分岐があるなど、
やや複雑なロジックを置いておく Controller Service Model Model Model
Rails × サービスレイヤー • だいたいのユースケースには必要ない ◦ 普通は数個のモデルに対して CRUD するだけで済むので、何も せずモデルとコントローラをつなぐだけのクラスが大量発生する
• このパターンは「エンタープライズアプリケーション」用である ◦ そもそも、サービスレイヤーは多数あるインターフェースに対して 共通のロジックを提供するためのパターン ▪ 普通の Web アプリケーションはせいぜい HTML と JSON API が必要な程度
Rails × サービスオブジェクト • Rails におけるビジネスロジックの担当は app/models ◦ ロジックを置く場所が2つあるので議論が必ず起こる ◦
今だけでなく未来に参画するメンバーまで含めて 基準を共有するのはほぼ不可能 • 「単にロジックをまとめただけ」の場所が出来上がりがち ◦ オブジェクト指向をちゃんとやるのはむずかしい ◦ まずは ActiveRecord と RDB をがっつり使い倒そう
Rails × フォームオブジェクト • そうは言っても、複雑なロジックを扱いたいときはある ◦ ユーザー登録処理とか ◦ 特定条件のときはバリデーションしないようにする、とか •
そういうときはフォームオブジェクトを使う ◦ フォームごとに異なるロジックを書けるようにし、 特定条件下での関心事を分離する ◦ app/forms を切ることもあるが、 管理できないほど増えるまでは app/models でもよさそう
Rails × フォームオブジェクト https://speakerdeck.com/igaiga/kaigionrails2024
Rails Way に乗る • rails new した時点では、app/services は切られない ◦ ActiveRecord
や ActiveModel の力を使って ロジックをモデルに書くのが Rails の基本 ◦ 「こういう設計に最初からなってるのは、やっぱ DHH って 先見の明があってすげーなと思う」
懇親会に行こう! • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い