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
4
1.9k
「今のプロジェクトいろいろ大変なんですよ、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
640
「ナントカLR」を整理する / Clarifying LR Algorithms
junk0612
1
410
From LALR to IELR: A Lrama's Next Step
junk0612
2
3.7k
RubyConf Taiwan / Understanding Parser Generators surrounding Ruby with Contributing Lrama
junk0612
1
5.1k
LL法とLR法の違いは?調べてみた!-完全版-/Comparing LL and LR parse algorithm -EX Edition-
junk0612
0
560
ESM Super LT/Comparing LL and LR parse algorithm
junk0612
1
110
Lrama へのコントリビューションを通して学ぶ Ruby のパーサジェネレータ事情
junk0612
4
5.3k
ソフトウェア開発とコミュニケーション / Communication in Software Development
junk0612
0
1.2k
アジャイルという「マインドセット」 / Mindset named Agile
junk0612
0
920
Other Decks in Programming
See All in Programming
詳細解説! ArrayListの仕組みと実装
yujisoftware
0
540
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
340
推し活としてのrails new/oshikatsu_ha_iizo
sakahukamaki
3
2k
Macとオーディオ再生 2024/11/02
yusukeito
0
320
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
katty0324
5
4.2k
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
4
1.9k
僕がつくった48個のWebサービス達
yusukebe
20
17k
ヤプリ新卒SREの オンボーディング
masaki12
0
110
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
phigasui
3
2.3k
Sidekiqで実現する 長時間非同期処理の中断と再開 / Pausing and Resuming Long-Running Asynchronous Jobs with Sidekiq
hypermkt
6
3k
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
9
3.1k
色々なIaCツールを実際に触って比較してみる
iriikeita
0
310
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
50
7.2k
The Language of Interfaces
destraynor
154
24k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
810
4 Signs Your Business is Dying
shpigford
180
21k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
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 って 先見の明があってすげーなと思う」
懇親会に行こう! • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い