「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night

After Kaigi on Rails 2024 LT Night での発表資料です。

Transcript

1. 「今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって……」 After Kaigi on Rails 2024 LT Night 株式会社タイミー様 東京本社 2024/11/12(火) 小林 純一 (@junk0612) 株式会社永和システムマネジメント アジャイル事業部 Sponsor Talk
2. 小林 純一 • X: @junk0612 • GitHub: ＠junk0612 • 永和システムマネジメント ◦ Rails エンジニア ◦ 構文解析器研究部員 • Lrama のコミッター • 趣味 ◦ パーサー ◦ 音楽ゲーム ◦ ボードゲーム ◦ 俳句
3. Kaigi on Rails お疲れ様でした！
5. 今回の担当 • Beer 🍻 • Dora 🔔
8. 提 供 情報化技術を通じて社会と共生する
9. 2024/09/07
12. 今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612
13. 今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612 えっ何、app/services の話？ @onk オレ、app/services にはちょっとうるさいよｗ @joker1007
14. app/services とかもあって…… @junk0612 えっ何、app/services の話？ @onk オレ、app/services にはちょっとうるさいよｗ @joker1007 実際、app/services ってちゃんと運用されること 少なくないですか？ だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね？ 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど @junk0612
15. いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら ないで models 配下に直接置いちゃったほうがいい。 @onk 実際、app/services ってちゃんと運用されること 少なくないですか？ だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね？ 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど。 @junk0612
16. いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら ないで models 配下に直接置いちゃったほうがいい。 @onk 結局のところ、rails new した時に作られるディレクトリ 以外に新しいディレクトリを作ろうとするのは Rails Way に乗らないことなんで基本的にやらないほうがいい んですよ。Form オブジェクトだったら許せる。複雑なビ ジネスロジックを扱いたいときっていうのはどうしてもあ るんで、それをモデルに書いて fat になるくらいだったら Form オブジェクトを models 配下に直接置くほうがい いですよ。 @joker1007
17. app/services が切られる理由(1) • サービスレイヤーに属するクラスの置き場所 ◦ 出典は PofEAA ◦ app/models 配下のクラスを 「ドメインモデル」として扱う ◦ ドメインモデルを操作して、処理を行う層 https://martinfowler.com/eaaCatalog/serviceLayer.html
18. app/services が切られる理由(2) • サービスオブジェクトの置き場所 ◦ Rails でのデザインパターンの1種 ◦ 複数のモデルにまたがったり 条件分岐があるなど、 やや複雑なロジックを置いておく Controller Service Model Model Model
19. Rails × サービスレイヤー • だいたいのユースケースには必要ない ◦ 普通は数個のモデルに対して CRUD するだけで済むので、何も せずモデルとコントローラをつなぐだけのクラスが大量発生する • このパターンは「エンタープライズアプリケーション」用である ◦ そもそも、サービスレイヤーは多数あるインターフェースに対して 共通のロジックを提供するためのパターン ▪ 普通の Web アプリケーションはせいぜい HTML と JSON API が必要な程度
20. Rails × サービスオブジェクト • Rails におけるビジネスロジックの担当は app/models ◦ ロジックを置く場所が2つあるので議論が必ず起こる ◦ 今だけでなく未来に参画するメンバーまで含めて 基準を共有するのはほぼ不可能 • 「単にロジックをまとめただけ」の場所が出来上がりがち ◦ オブジェクト指向をちゃんとやるのはむずかしい ◦ まずは ActiveRecord と RDB をがっつり使い倒そう
21. Rails × フォームオブジェクト • そうは言っても、複雑なロジックを扱いたいときはある ◦ ユーザー登録処理とか ◦ 特定条件のときはバリデーションしないようにする、とか • そういうときはフォームオブジェクトを使う ◦ フォームごとに異なるロジックを書けるようにし、 特定条件下での関心事を分離する ◦ app/forms を切ることもあるが、 管理できないほど増えるまでは app/models でもよさそう
22. Rails × フォームオブジェクト https://speakerdeck.com/igaiga/kaigionrails2024
23. Rails Way に乗る • rails new した時点では、app/services は切られない ◦ ActiveRecord や ActiveModel の力を使って ロジックをモデルに書くのが Rails の基本 ◦ 「こういう設計に最初からなってるのは、やっぱ DHH って 先見の明があってすげーなと思う」
24. 懇親会に行こう！ • こういうおもしろい話があちこちで行われていてためになる • 本編で聞けなかった細かい話や深い話も聞ける • 特定の分野に詳しい人・ハマってる人の話は良い