Rails Developer Meetup2018 Day2のスポンサーセッション時のスライドです。 https://techplay.jp/event/655769

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には ActiveRecord という強力なModelの指針がある
Rails Guide曰く、 Active Recordとは、MVCで言うところのM、つまりモ
デルに相当するもの
Railsの出発点は Model = ActiveRecord

17. しかしRailsならではのつらみ
時代がたち、出発点がActiveRecordであることから来るつらみが溢
れてきた
PoEAAやDDDで紹介されているようなActiveRecord以外のModel
の設計パターンが非常に取りづらい（相性が悪い）
Railsならではのアプローチを模索していく必要がある

18. ここ数年のRailsエンジニアのModelとの戦いは、
ActiveRecord = Model という固定概念からいかに脱却するかの戦い

19. Decorator
Helperが関数的であり、OOP的に扱いたいという欲求から生まれた
いわゆるデコレータパターン
データオブジェクトからViewに対する振る舞いを分離する

20. Form
Webアプリケーションで複雑になりがちなFormをオブジェクト化
したもの
データオブジェクトからFormに表示するための振る舞いを分離する
値オブジェクト的な側面も持つ
場合によってはvalidationなどの責務も持つ

21. Service
ビジネスロジックの一部をオブジェクト化したもの
複数のデータオブジェクトのトランザクション境界をActiveRecord
から分離する
DDD本来のドメインモデルからは少し変わっている（が、気にしな
くて良い）

22. エトセトラ
Serviceクラスが銀の弾丸ではないし、今まで語られてきたパターンだけ
がModelの設計パターンではない
Repository(Query) 複数のARからデータを1つのオブジェクト、
あるいはそのコレクションにマッピングする
Policy banken gem。ユーザの権限をオブジェクト化する
Serializer active_record_serializers gem。jsonなどのデータ形
式にキャストする
Value Object 値そのものをオブジェクト化したもの。
Immutableが望ましい。Date、URI、Pathnameなど。
Validator 、 Callback 、etc....

23. サービスクラスとかの前に考えたいこと
自分たちのアプリケーションはどのぐらいの規模になりそうか？
Modelの設計方針はどうするのか？
アプリケーションはどういう振る舞いが期待されるのか？
WebAPI？
Webアプリケーション？

24. まとめ
設計とは地図のようなもの。チーム全体で「自分たちのアプリケーショ
ン」に対する共通認識を持つのが重要だと思います。
ModelのRailは自分たちで引いていきましょう！

25. 余談： 初日の感想
Railsの設計論はModelを卒業してアプリケーション全体のデザインに届
きつつあるのかなと思いました

26. We are hiring!
株式会社Aimingではエンジニアを募集しています！
ゲームのWebAPI → 「普通のWebアプリケーション」ではない
Railsの設計に興味がある
社内ツール→ 「普通のWebアプリケーション」なRailsの設計に興
味がある