UseCaseクラスを使って FatControllerやFatModelにしない

Railsアプリ開発で陥りがちなFatController／FatModel問題を、可読性低下・保守性悪化・コード重複助長という視点から整理し、その根本原因となる「関心事の分離不足」を解説します。Rails勉強会 (1)
UseCaseクラスを導入することで、Controllerはリクエスト受け取りとUseCase呼び出しのみ、ModelはDB操作に専念し、ビジネスロジックは業務フローに特化したクラスに切り分ける設計手法を、豊富なサンプルコードとともに紹介します。Rails勉強会 (1)
また、interactor gemを使ったユースケース実装の実例も取り上げ、保守性と可読性を大幅に向上させる具体的なアプローチをお見せします。

Transcript

1. UseCaseクラスを使って FatControllerやFatModelにしない 鈴木まー　 Gotanda.rb#62
2. 自己紹介 鈴木まー RailsでDDDを会社に導入定着させて 今はCQRS/ESの仕組みを フルスクラッチしながら勉強している 設計についていろんな勉強会で登壇している
3. 本題に入る前に質問
4. FatController OR FatModel になって開発しづらく なっている人?
5. FatController/FatModel になるとどのように開発しづ らくなるのか
6. 可読性の低下 多くの責務が一つに詰め込まれ、 処理の流れが見えにくくなる 保守性の悪化 機能追加や修正で広範囲に手を入れる必要があり、変更 時のリスクが大きい コード重複の助長 汎用的な処理が切り出しづらく、結果として同じロジッ クを複数箇所にコピーしてしまう
7. FatController OR FatModel になる原因は関心事の分離ができ ていないからどちらかがFatになる
8. 関心事の分離とは 処理や役割を「ひとつずつ」に分けて、 それぞれ専用の場所で実装すること。 Controllerは リクエストを受けて、認証をして 処理を依頼してリクエストを返す ModelはRDBなどの特定のDBに 対する操作とレコードを抽象化する操作
9. 関心事の分離にクラスの目的を見直した結果 ControllerとModelはシンプルになったが、 ビジネスロジックを書く場所がなくなった
10. ビジネスロジックは種類ごとに UseCaseクラスに書く
11. そもそもユースケースとは 『在庫確認 → 注文 → 決済 → 通知』 のように、
 ユーザーが達成したい目的をステップごとに 実現するための処理手順をまとめたもの
12. 在庫の更新 商 品 を 購 入 す る ユ
 | ス ケ | ス 在庫の確認 料金の受取 配送したこと メールで伝える
13. UseCaseクラスを使うまえ
14. これと似たような複雑性が あるUpdateのようなアク ションメソッドが存在する
15. REST原則にしたがうと一つのリソースに 対してGETやUPDATEなどのアクション メソッドが存在する 一つのアクションメソッドのために privateメソッドを実装するとどのメソッド がどのアクションメソッドで使うのかがわ かりづらい
16. Modelにビジネスロジックを書くとして明 らかに関係していないテーブルへの操作を かいたり、明らかに違う関心事を２つ書くの でカオスなクラスになってしまう ビジネス ロジック ActiveRecord RDBに関す ること
17. UseCaseクラスを使ったあと
18. このメソッドの大きさならRESTtfulのすべての アクションメソッドを書いてもFatにならない
19. ビジネスロジックを実行するときに必要となる DBアクセスをUseCaseから扱いしやすくする だけでいいのでシンプルになる Modelについて
20. UseCase クラスの 内容
21. これはRailsWay ではないのでは?
22. MVCパターンではないので純粋なRailsWay ではなくなるが、Fatになりやすいビジネス ロジックを専門のクラスになるので、 MVCパターンを守りやすくなる
23. コントローラー モデル ユースケース ビュー
24. コントローラーとモデルの間に 特定のビジネスロジック をおこなうための中継役 のクラスが入っていると思うと理解しやすい
25. サービスクラスとは違うの？
26. Serviceクラスはよくある銀行口座間のやり 取りなどのユースケース内の一つの複雑な関 心事に対しての処理を実装をしているもの UseCaseクラス内でServiceクラスを使って 複雑な関心ごとを実装することはある
27. 複雑なユースケースの場合は、 ユースケース内の特定の複雑なことをするサー ビスクラスが複数存在することはある 複雑なユースケース サービス クラス サービス クラス サービス クラス
28. どう実装をするの？
29. interactorという長年開発 されているGemがある https://github.com/collectiveidea/interactor
30. サンプルコード
31. まとめ Fat Controller/Fat Modelについて 問題点 ControllerやModelにビジネスロジックが集中すると、 可読性や保守性が低下します 。 この根本的な原因は、 「関心事の分離」ができていないことです
32. 解決策 UseCaseクラスの導入 「ユーザーが行う一連の処理」を ビジネスロジックとして UseCaseクラスに分離します 。 Controllerはリクエストを受け付けて UseCaseを呼び出すだけになり、 ModelはDB操作に専念するため、 それぞれがシンプルになります 。
33. 結果 保守性の高いアプリケーションへ 責務が明確に分離されることで、 コードの見通しが良くなり、 変更に強い構造を実現できます 。 このアプローチは、純粋なMVCパターンを 守りやすくするための有効な手段です
35. ご清聴ありがとう ございました