サービスクラス、その前に

Rails Developer Meetup2018 Day2のスポンサーセッション時のスライドです。

https://techplay.jp/event/655769

Transcript

1. サー ビスクラス、 その前に
2. 自己紹介 植森 康友 株式会社Aiming 大阪スタジオ所属 主な仕事 WebAPI 開発 社内ツー ル開発 devops Docker おじさん 最近はkubernetes も
3. 株式会社Aiming について Rails の使い所 ゲー ムのWebAPI 社内ツー ル、 管理ツー ルなどのWeb アプリケー ション
4. 今日の話 サー ビスクラスなんとなくわかるけど、 ぐらいの人向け 個人的にサー ビスクラスとかそういうのの前に知っておいてほしい ことを話します ちょっとエモめ
5. ドメインサー ビス Rails で多く語られてきた「 サー ビスクラス」（ に近いもの） ビジネスロジックを表現するための一つの手段 Rails の文脈ではだいたい複数のモデルにまたがる処理を責務として 持つクラス どのドメインモデルにも紐付かないビジネスロジックを表現するた めのもの 例えば キャラクター 作成時には初期武器と初期ジョブを付与する ログイン時にギフトのマスタ情報を参照して受け取ってないギ フトをキャラクター に付与する
6. ドメインサー ビス Rails で多く語られてきた「 サー ビスクラス」（ に近いもの） ビジネスロジックを表現するための一つの手段 Rails の文脈ではだいたい複数のモデルにまたがる処理を責務として 持つクラス どのドメインモデルにも紐付かないビジネスロジックを表現するた めのもの 例えば キャラクター 作成時には初期武器と初期ジョブを付与する ログイン時にギフトのマスタ情報を参照して受け取ってないギ フトをキャラクター に付与する
7. ビジネスロジックってなんだ？？？
8. ビジネスロジック デー タに対する処理手順といったようなものを指す ビジネスロジックという用語は明確な定義がなく、 人によって意味 が異なる可能性がある。
9. そもそもMVC とは何だったのか？ よくある説明 Controller: Model とView をつなぐもの View: ユー ザへのプレゼンテー ション Model: ビジネスロジック
10. Model とはビジネスロジックである。
11. ビジネスロジックという用語は明確な定義がない
12. ('‑') ？？？
13. MVC とは何だったのか？ 参考： あの日見たM V Whatever のModel を僕たちはまだ知らない View: ユー ザへのプレゼンテー ション Controller: Model とView をつなぐもの Model: View とController 以外の全て そもそもMVC はプレゼンテー ションとモデルを分割するためのもの。
14. MVC はModel の設計方針について何一つ語ってはいない
15. じゃあModel の設計どうしたらいいの？
16. Rails はMVC フレー ムワー クである Model の設計方針はエンジニアの手に委ねられている 当然の話として、 アプリケー ションの振る舞いはアプリケー ション によって違う 例えば、WebAPI とWeb アプリケー ションの設計は同じように はいかない ただしRails には A c t i v e R e c o r d という強力なModel の指針がある Rails Guide 曰く、 A c t i v e R e c o r d とは、M V C で言うところのM 、 つまりモ デルに相当するもの Rails の出発点は M o d e l = A c t i v e R e c o r d
17. しかしRails ならではのつらみ 時代がたち、 出発点がActiveRecord であることから来るつらみが溢 れてきた PoEAA やDDD で紹介されているようなActiveRecord 以外のModel の設計パター ンが非常に取りづらい（ 相性が悪い） Rails ならではのアプロー チを模索していく必要がある
18. ここ数年のRails エンジニアのModel との戦いは、 A c t i v e R e c o r d = M o d e l という固定概念からいかに脱却するかの戦い
19. Decorator Helper が関数的であり、OOP 的に扱いたいという欲求から生まれた いわゆるデコレー タパター ン デー タオブジェクトからView に対する振る舞いを分離する
20. Form Web アプリケー ションで複雑になりがちなForm をオブジェクト化 したもの デー タオブジェクトからForm に表示するための振る舞いを分離する 値オブジェクト的な側面も持つ 場合によってはvalidation などの責務も持つ
21. Service ビジネスロジックの一部をオブジェクト化したもの 複数のデー タオブジェクトのトランザクション境界をActiveRecord から分離する DDD 本来のドメインモデルからは少し変わっている（ が、 気にしな くて良い）
22. エトセトラ Service クラスが銀の弾丸ではないし、 今まで語られてきたパター ンだけ がModel の設計パター ンではない R e p o s i t o r y ( Q u e r y ) 複数のAR からデー タを1 つのオブジェクト、 あるいはそのコレクションにマッピングする P o l i c y banken gem。 ユー ザの権限をオブジェクト化する S e r i a l i z e r active_record_serializers gem。json などのデー タ形 式にキャストする V a l u e O b j e c t 値そのものをオブジェクト化したもの。 Immutable が望ましい。Date、URI、Pathname など。 V a l i d a t o r 、 C a l l b a c k 、etc....
23. サー ビスクラスとかの前に考えたいこと 自分たちのアプリケー ションはどのぐらいの規模になりそうか？ Model の設計方針はどうするのか？ アプリケー ションはどういう振る舞いが期待されるのか？ WebAPI？ Web アプリケー ション？
24. まとめ 設計とは地図のようなもの。 チー ム全体で「 自分たちのアプリケー ショ ン」 に対する共通認識を持つのが重要だと思います。 Model のRail は自分たちで引いていきましょう！
25. 余談： 初日の感想 Rails の設計論はModel を卒業してアプリケー ション全体のデザインに届 きつつあるのかなと思いました
26. We are hiring! 株式会社Aiming ではエンジニアを募集しています！ ゲー ムのWebAPI → 「 普通のWeb アプリケー ション」 ではない Rails の設計に興味がある 社内ツー ル → 「 普通のWeb アプリケー ション」 なRails の設計に興 味がある