Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

8,508 views

Published on

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

https://techplay.jp/event/655769

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

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

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

×