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.1k
「今のプロジェクトいろいろ大変なんですよ、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
710
「ナントカLR」を整理する / Clarifying LR Algorithms
junk0612
1
430
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.2k
LL法とLR法の違いは?調べてみた!-完全版-/Comparing LL and LR parse algorithm -EX Edition-
junk0612
0
570
ESM Super LT/Comparing LL and LR parse algorithm
junk0612
1
110
Lrama へのコントリビューションを通して学ぶ Ruby のパーサジェネレータ事情
junk0612
4
5.4k
ソフトウェア開発とコミュニケーション / Communication in Software Development
junk0612
0
1.2k
アジャイルという「マインドセット」 / Mindset named Agile
junk0612
0
920
Other Decks in Programming
See All in Programming
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
870
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
CSC509 Lecture 11
javiergs
PRO
0
180
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
2
1.1k
AI時代におけるSRE、 あるいはエンジニアの生存戦略
pyama86
6
1.1k
初めてDefinitelyTypedにPRを出した話
syumai
0
400
弊社の「意識チョット低いアーキテクチャ」10選
texmeijin
5
24k
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
9
3.3k
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
役立つログに取り組もう
irof
28
9.6k
EventSourcingの理想と現実
wenas
6
2.3k
Laravel や Symfony で手っ取り早く OpenAPI のドキュメントを作成する
azuki
1
110
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
95
5.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
A Philosophy of Restraint
colly
203
16k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Agile that works and the tools we love
rasmusluckow
327
21k
Designing for humans not robots
tammielis
250
25k
Building Adaptive Systems
keathley
38
2.3k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
120
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 って 先見の明があってすげーなと思う」
懇親会に行こう! • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い