Slide 1

Slide 1 text

「今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって……」 After Kaigi on Rails 2024 LT Night 株式会社タイミー様 東京本社 2024/11/12(火) 小林 純一 (@junk0612) 株式会社永和システムマネジメント アジャイル事業部 Sponsor Talk

Slide 2

Slide 2 text

小林 純一 ● X: @junk0612 ● GitHub: @junk0612 ● 永和システムマネジメント ○ Rails エンジニア ○ 構文解析器研究部員 ● Lrama のコミッター ● 趣味 ○ パーサー ○ 音楽ゲーム ○ ボードゲーム ○ 俳句

Slide 3

Slide 3 text

Kaigi on Rails お疲れ様でした!

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

今回の担当 ● Beer 🍻 ● Dora 🔔

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

提 供 情報化技術を通じて社会と共生する

Slide 9

Slide 9 text

2024/09/07

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612

Slide 13

Slide 13 text

今のプロジェクトいろいろ大変なんですよ、 app/services とかもあって…… @junk0612 えっ何、app/services の話? @onk オレ、app/services にはちょっとうるさいよw @joker1007

Slide 14

Slide 14 text

app/services とかもあって…… @junk0612 えっ何、app/services の話? @onk オレ、app/services にはちょっとうるさいよw @joker1007 実際、app/services ってちゃんと運用されること 少なくないですか? だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね? 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど @junk0612

Slide 15

Slide 15 text

いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら ないで models 配下に直接置いちゃったほうがいい。 @onk 実際、app/services ってちゃんと運用されること 少なくないですか? だいたい歴史が長くなっていくにつ れて「なんでも置き場」みたいになっていって、なんかこう 荒れ果てた場所になっていくイメージがあるんですけど、 あれなんでなんですかね? 個人的にはやっぱりメンバー が変わっていくと引継ぎがされなくて思想が薄れていく のかなって気がしてるんですけど。 @junk0612

Slide 16

Slide 16 text

いや、そもそも app/services はねぇ、作らないほうが いいんですよ。サービスレイヤー作ると、もらったリクエス トをそのままモデルに流してコントローラに返すだけのも のすごく薄っぺらいクラスがいくつもできることになっ ちゃってイケてないですよね。ビジネスロジックの置き場 は app/models であるべきなんで、ディレクトリを切ら ないで models 配下に直接置いちゃったほうがいい。 @onk 結局のところ、rails new した時に作られるディレクトリ 以外に新しいディレクトリを作ろうとするのは Rails Way に乗らないことなんで基本的にやらないほうがいい んですよ。Form オブジェクトだったら許せる。複雑なビ ジネスロジックを扱いたいときっていうのはどうしてもあ るんで、それをモデルに書いて fat になるくらいだったら Form オブジェクトを models 配下に直接置くほうがい いですよ。 @joker1007

Slide 17

Slide 17 text

app/services が切られる理由(1) ● サービスレイヤーに属するクラスの置き場所 ○ 出典は PofEAA ○ app/models 配下のクラスを 「ドメインモデル」として扱う ○ ドメインモデルを操作して、処理を行う層 https://martinfowler.com/eaaCatalog/serviceLayer.html

Slide 18

Slide 18 text

app/services が切られる理由(2) ● サービスオブジェクトの置き場所 ○ Rails でのデザインパターンの1種 ○ 複数のモデルにまたがったり 条件分岐があるなど、 やや複雑なロジックを置いておく Controller Service Model Model Model

Slide 19

Slide 19 text

Rails × サービスレイヤー ● だいたいのユースケースには必要ない ○ 普通は数個のモデルに対して CRUD するだけで済むので、何も せずモデルとコントローラをつなぐだけのクラスが大量発生する ● このパターンは「エンタープライズアプリケーション」用である ○ そもそも、サービスレイヤーは多数あるインターフェースに対して 共通のロジックを提供するためのパターン ■ 普通の Web アプリケーションはせいぜい HTML と JSON API が必要な程度

Slide 20

Slide 20 text

Rails × サービスオブジェクト ● Rails におけるビジネスロジックの担当は app/models ○ ロジックを置く場所が2つあるので議論が必ず起こる ○ 今だけでなく未来に参画するメンバーまで含めて 基準を共有するのはほぼ不可能 ● 「単にロジックをまとめただけ」の場所が出来上がりがち ○ オブジェクト指向をちゃんとやるのはむずかしい ○ まずは ActiveRecord と RDB をがっつり使い倒そう

Slide 21

Slide 21 text

Rails × フォームオブジェクト ● そうは言っても、複雑なロジックを扱いたいときはある ○ ユーザー登録処理とか ○ 特定条件のときはバリデーションしないようにする、とか ● そういうときはフォームオブジェクトを使う ○ フォームごとに異なるロジックを書けるようにし、 特定条件下での関心事を分離する ○ app/forms を切ることもあるが、 管理できないほど増えるまでは app/models でもよさそう

Slide 22

Slide 22 text

Rails × フォームオブジェクト https://speakerdeck.com/igaiga/kaigionrails2024

Slide 23

Slide 23 text

Rails Way に乗る ● rails new した時点では、app/services は切られない ○ ActiveRecord や ActiveModel の力を使って ロジックをモデルに書くのが Rails の基本 ○ 「こういう設計に最初からなってるのは、やっぱ DHH って 先見の明があってすげーなと思う」

Slide 24

Slide 24 text

懇親会に行こう! ● こういうおもしろい話があちこちで行われていてためになる ● 本編で聞けなかった細かい話や深い話も聞ける ● 特定の分野に詳しい人・ハマってる人の話は良い