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.6k
「今のプロジェクトいろいろ大変なんですよ、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
The Implementations of Advanced LR Parser Algorithm
junk0612
3
1.6k
LR で JSON パーサーを作る / Coding LR JSON Parser
junk0612
2
1.5k
「ナントカLR」を整理する / Clarifying LR Algorithms
junk0612
1
560
From LALR to IELR: A Lrama's Next Step
junk0612
2
4.3k
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
1k
ESM Super LT/Comparing LL and LR parse algorithm
junk0612
1
170
Lrama へのコントリビューションを通して学ぶ Ruby のパーサジェネレータ事情
junk0612
4
7k
ソフトウェア開発とコミュニケーション / Communication in Software Development
junk0612
0
1.3k
Other Decks in Programming
See All in Programming
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
36
23k
Claude Codeの使い方
ttnyt8701
1
120
DroidKnights 2025 - 다양한 스크롤 뷰에서의 영상 재생
gaeun5744
3
280
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
230
KotlinConf 2025 現地参加の土産話
n_takehata
0
100
Parallel::Pipesの紹介
skaji
2
910
AIエージェントによるテストフレームワーク Arbigent
takahirom
0
380
統一感のある Go コードを生成 AI の力で手にいれる
otakakot
0
3k
CSC307 Lecture 17
javiergs
PRO
0
120
Rails産でないDBを Railsに引っ越すHACK - Omotesando.rb #110
lnit
1
160
都市をデータで見るってこういうこと PLATEAU属性情報入門
nokonoko1203
1
450
Webからモバイルへ Vue.js × Capacitor 活用事例
naokihaba
0
700
Featured
See All Featured
Statistics for Hackers
jakevdp
799
220k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
123
52k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
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 って 先見の明があってすげーなと思う」
懇親会に行こう! • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い