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
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/Aft...
Search
Junichi Kobayashi
November 12, 2024
Programming
5
2.7k
「今のプロジェクトいろいろ大変なんですよ、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
rage against annotate_predecessor
junk0612
0
170
The Implementations of Advanced LR Parser Algorithm
junk0612
3
2k
LR で JSON パーサーを作る / Coding LR JSON Parser
junk0612
2
1.6k
「ナントカLR」を整理する / Clarifying LR Algorithms
junk0612
1
590
From LALR to IELR: A Lrama's Next Step
junk0612
2
4.5k
RubyConf Taiwan / Understanding Parser Generators surrounding Ruby with Contributing Lrama
junk0612
2
6.9k
LL法とLR法の違いは?調べてみた!-完全版-/Comparing LL and LR parse algorithm -EX Edition-
junk0612
0
1.2k
ESM Super LT/Comparing LL and LR parse algorithm
junk0612
1
180
Lrama へのコントリビューションを通して学ぶ Ruby のパーサジェネレータ事情
junk0612
4
7.1k
Other Decks in Programming
See All in Programming
プロパティベーステストによるUIテスト: LLMによるプロパティ定義生成でエッジケースを捉える
tetta_pdnt
0
4.3k
Rancher と Terraform
fufuhu
2
550
CloudflareのChat Agent Starter Kitで簡単!AIチャットボット構築
syumai
2
510
Kiroで始めるAI-DLC
kaonash
2
630
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
230
GitHubとGitLabとAWS CodePipelineでCI/CDを組み比べてみた
satoshi256kbyte
4
250
請來的 AI Agent 同事們在寫程式時,怎麼用 pytest 去除各種幻想與盲點
keitheis
0
130
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
540
AIと私たちの学習の変化を考える - Claude Codeの学習モードを例に
azukiazusa1
11
4.4k
アルテニア コンサル/ITエンジニア向け 採用ピッチ資料
altenir
0
110
私の後悔をAWS DMSで解決した話
hiramax
4
210
OSS開発者という働き方
andpad
5
1.7k
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
How to Ace a Technical Interview
jacobian
279
23k
How GitHub (no longer) Works
holman
315
140k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
3k
We Have a Design System, Now What?
morganepeng
53
7.8k
A better future with KSS
kneath
239
17k
Faster Mobile Websites
deanohume
309
31k
Music & Morning Musume
bryan
46
6.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
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 って 先見の明があってすげーなと思う」
懇親会に行こう! • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い