Rails サービスクラス再考 / have a rethink on Rails service class

Rails サービスクラス再考 #meguro.rb 2018/05/24 @suusan2go

自己紹介 • Kenta Suzuki / @suusan2go • M3,inc / Software
Engineer • 経験値で言うとこんな感じ ◦ Ruby > JavaScript > Kotlin(ServerSide) > Golang • 直近はKotlinでAPIサーバ + Nuxt.js書いてました

(Railsの)サービスクラスとは • 7 Patterns to Refactor Fat ActiveRecord Models ◦
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳） • ActiveRecordのクラスから責務を分割するための考え方として登場した • 自分が初めて業務でみたのは2015年 • Rails標準ではなく、各社各々の考え方で実装されている • 最近はディスられ気味

なぜ最近はRailsにおけるサービスクラスの評判が悪いのか？

サービスクラス自体は一般的な実装パターンのはずでサービスクラス = 悪ではないよね？ (Spring + Kotlin + DDDプロジェクトをやった感想)

というわけで Railsにおけるサービスクラスについて改めて考えてみました

そもそもサービスクラスとは何なのか？個人的な認識では以下のパターンで語られる事が多い • DAO + サービスパターン • DDDにおけるアプリケーションサービス / ドメインサー
ビスとして使うパターン

DAO + サービスパターンな使い方 • ActiveRecordをDBへのアクセス層としてしか使わない ◦ => ActiveRecordにメソッド定義しない • ビジネスロジックはサービスクラスに押し込む
• 新規Railsアプリに最初からサービスクラスを導入するとこのパターンになっていることがあるらしい • ロジックの重複が起こりやすく、これは自分もアンチパターンだと思う

class CompleteTaskService def call(task:, user:) if task.completed_at.nil? task.update( hoge: "piyo",
completed_at: Time.current) else task.update( piyo: "fuga") end UserMailer.task_completed(user: user, task: task).deliver_now end end

pros / cons • pros ◦ ActiveRecordの肥大化は防げる • cons ◦
ActiveRecordの肥大化は防げるが、サービスクラスは肥大化する ◦ ロジックの重複が起きやすい ▪ 「タスクを完了にするときにはXXX、XXXを更新する」みたいなビジネスルールを一箇所で守れない ▪ タスクは完了するかつ、XXXもするみたいなサービスが出来たときにどうなるだろう？一括でタスク完了するサービスが必要になったら？

DDDのアプリケーション/ドメインサービス的な使い方 • DDD的に考えるとapp/models配下はEntity(= AR)、ValueObject( != AR)、Repository(=AR)と考えられると思う • 個人的には、サービスクラスをapp/servicesに於いてレイヤーを作る構成にするならアプリケーションサービスとして扱うべきだと思う(ビジネスロジックはあくまでapp/modelsで担うということ)

class CompleteTaskService def call(task:, user:) task.complete #　あくまでTaskに定義されているメソッドを呼び出すだけ UserMailer.task_completed( user: user,
task: task).deliver_now end end class Task < ApplicationRecord def complete #　省略... end end

# タスクを一括更新する場合にメールの通知の仕方を変えたいといったのにも対応できる class BulkCompleteTaskService def call(tasks:, user:) tasks.each do |task|
task.complete end UserMailer.tasks_completed( user: user, tasks: tasks).deliver_now end end

pros / cons • pros ◦ トランザクション、セキュリティの関心事などをビジネスロジックから分離できる ◦ 今回でいうとタスクの完了と、通知という関心事を分離している •
cons ◦ エラーハンドリング、命名規則など考えることは増える (前述の例ではエラーハンドリング全然考えられてないw) ◦ チーム内でサービス層の役割について認識があっていないと、似たような処理が分散し、ロジックの置き場に一貫性がなくなる (今日は主にこっちについて話します )

なぜサービスクラスがアンチパターン化するのか • レイヤーとしてサービスを置くなら、サービスクラスはあくまで app/models配下のpublic methodをハンドリングするだけになるはず • これを守らないとアンチパターン化する傾向に有る気がする。過去に見た・やってしまった経験があるのは以下 ◦ 肥大化したモデルのメソッドをただサービスクラスに移す
◦ 複数モデルを触るのでサービスクラスにする

肥大化したモデルのメソッドをただサービスクラスに移すコード例 # これをサービス化する class Task < ApplicationRecord def complete(user:)
update(hoge: "piyo", completed_at: Time.current) 　　　task.comments.each do |comment| comment.update( hoge: fuga) end task.owner.update( "piyo") if task.piyopiyo? 　　　UserMailer.send_hoge_mail(task).deliver_later if task.ponyo? # みたいな処理が100行 end end

肥大化したモデルのメソッドをただサービスクラスに移すコード例 # DAO + サービスパターンと同じく、本来 Taskが持っているべき知識が漏れてしまっている # Task クラスの中に他にも
`completed_at` を更新するメソッドがいたりすると責務が曖昧になる class CompleteTaskService def call(task:, user:) update(hoge: "piyo", completed_at: Time.current) 　　　task.comments.each do |comment| comment.update( hoge: fuga) end task.owner.update( piyo: "piyo") if task.piyopiyo? 　　　UserMailer.send_hoge_mail(task).deliver_later if task.ponyo? # みたいな処理が100行 end end

肥大化したモデルのメソッドをただサービスクラスに移す • DAO + サービスパターンのようなデメリットが出て来る • 本来モデルが持つべき責務までサービスクラスに漏れてしまっている • 処理としては同じことをやっているので、モデルにかけばイイのか？サービスにすべきか？が曖昧になっていく
• Userモデルが肥大化したので今後はUserServiceに処理書いていく！みたいなのも同じパターン

複数モデルを触るのでサービスクラスにするコード例 # タスクへのコメント追加サービス # このコメントの生成ルールを必ず守らなければいけないとしたら、サービスにこのロジックを置くのは適切なのか？ class CreateTaskCommentService def call(task:,
content:, author:) # タスクが完了してたらコメントは追加できない if task.completed? raise "This task is already completed" end # タスクの作者はコメントできない。変な仕様だけど例なので許してください :bow: if task.owner?(author) 　　　 raise "Task owner can’t add comment" end Comment.create!(body: content, task_id: task.id, author_id: author.id) end end

複数モデルを触るのでサービスクラスにする • オブジェクトの生成条件が守れなくなる • これも本来クラスが持つべき責務が漏れ出してしまっている • 複数のモデルを触るとき〜のような画一的なルールではなくて、誰が担う責務なのかをまず考えるべき(集約の境界を意識する)

TaskクラスがCommentの生成の責務を保つ場合の例 class Task < ApplicationRecord def add_comment(body:, author:) # タスクが完了してたらコメントは追加できない
if completed? raise "This task is already completed" end # タスクの作者はコメントできない。変な仕様だけど例なので許してください :bow: if owner?(author) raise "Task owner can't add comment" end task.comments.create!( body: content, task_id: id, author_id: author.id) end end

Fat Modelの解消にサービスクラスは有用なのか？ • 前述した通り、サービスクラスはあくまで、app/models配下に定義されたビジネスロジック、それ以外の関心事(外部とのAPI通信、プッシュ通知、メール送信など)をハンドリングする立場になるべき • 単純に肥大化したモデルの一部のメソッド / 特定のパターンでサービスクラス
化というのは分かりやすいし取り組み安いけど、モデルとサービスの責務がカオス化する • というわけで、サービスクラス = FatModel解消のためのものではないし、レイヤーや責務について共通認識がないチームだと厳しい (サービスに限った話ではないけど…) ※逆にそういうチームなら全然あり

DHHはサービスクラスのことをどう思ってるのかあくまでCallback / Concern機能の解説の文脈ではあるけど、以下のように言っているっぽい？ Service Object/Form Object 、トランザクションスクリプトのようなもので綺麗に制御できるとは思わない https://www.youtube.com/watch?v=M3JPTOTqsnE&list=PL9wALaIpe0Py6E_oHCgTrD6FvFETwJLlx&index=2

個人的には • サービスクラス自体が悪ではないはずだけど、RailsはMVC + ActiveRecordの世界観が強いので、導入すると考えることが増えがち。 • プロジェクトの途中から導入すると、コントローラによって全然書き方違うみたいなことになりがち。この場合どうするん？みたいな話になりがち。 •
メソッドの置き場に困ったときに、サービスクラスに逃げるのではなく、まずは ActiveRecordで表現できていない(= DBに直接は紐付かない)概念がないか探してみて、それを app/models に落とし込んでいくとよいのでは

非ARなクラスを作る例 # 実装は適当ですが、タスクのリストを扱う場合はこんな概念を検討してみてもいいかもしれない class UserTaskList def initialize(tasks:, user:) @tasks =
tasks @user = user end def complete_all @tasks.each do |task| task.complete end UserMailer.tasks_completed(user: @user, tasks: @tasks).deliver_now end 　# 省略 def expired_tasks end end

app/modelsに非ARなクラスを作るのはRails Wayじゃない？ https://www.youtube.com/watch?v=hkmrfjex7jI&t=3s DHHもやってるっぽいし多分大丈夫！

まとめ • なぜ最近になってRailsのサービスクラスがディスられがちなのか考えてみました • サービスクラス自体は悪いものではないはずですが、Railsの世界で、かつFat Modelの解消のために使うのはあまり良い結果にならないかもしれません • サービスクラスの前に、非ARなクラスで表現ができないかを考えましょう。 •
何かのツールやレイヤーを導入したら魔法のように設計が上手くいくなんてことは殆どないので、まずは歯を食いしばってオブジェクト指向していきましょう！

参考文献 https://speakerdeck.com/joker1007/realworld-domain-model-on-rails https://qiita.com/joker1007/items/25de535cd8bb2857a685 https://qiita.com/klriutsa/items/8d7381f437c225c64a5f http://blog.j5ik2o.me/entry/2016/03/07/034646 Special Thanks レビューありがとう https://github.com/negito6

Rails サービスクラス再考 / have a rethink on Rails service class

Rails サービスクラス再考 / have a rethink on Rails service class

Kenta Suzuki

More Decks by Kenta Suzuki

Other Decks in Programming

Featured

Transcript

Rails サービスクラス再考 #meguro.rb 2018/05/24 @suusan2go

自己紹介 • Kenta Suzuki / @suusan2go • M3,inc / Software

(Railsの)サービスクラスとは • 7 Patterns to Refactor Fat ActiveRecord Models ◦

なぜ最近はRailsにおけるサービスクラスの評判が悪いのか？

サービスクラス自体は一般的な実装パターンのはずでサービスクラス = 悪ではないよね？ (Spring + Kotlin + DDDプロジェクトをやった感想)

というわけで Railsにおけるサービスクラスについて改めて考えてみました

そもそもサービスクラスとは何なのか？個人的な認識では以下のパターンで語られる事が多い • DAO + サービスパターン • DDDにおけるアプリケーションサービス / ドメインサー

DAO + サービスパターンな使い方 • ActiveRecordをDBへのアクセス層としてしか使わない ◦ => ActiveRecordにメソッド定義しない • ビジネスロジックはサービスクラスに押し込む

class CompleteTaskService def call(task:, user:) if task.completed_at.nil? task.update( hoge: "piyo",

pros / cons • pros ◦ ActiveRecordの肥大化は防げる • cons ◦

class CompleteTaskService def call(task:, user:) task.complete #　あくまでTaskに定義されているメソッドを呼び出すだけ UserMailer.task_completed( user: user,

# タスクを一括更新する場合にメールの通知の仕方を変えたいといったのにも対応できる class BulkCompleteTaskService def call(tasks:, user:) tasks.each do |task|

pros / cons • pros ◦ トランザクション、セキュリティの関心事などをビジネスロジックから分離できる ◦ 今回でいうとタスクの完了と、通知という関心事を分離している •

肥大化したモデルのメソッドをただサービスクラスに移すコード例 # これをサービス化する class Task < ApplicationRecord def complete(user:)

肥大化したモデルのメソッドをただサービスクラスに移すコード例 # DAO + サービスパターンと同じく、本来 Taskが持っているべき知識が漏れてしまっている # Task クラスの中に他にも

TaskクラスがCommentの生成の責務を保つ場合の例 class Task < ApplicationRecord def add_comment(body:, author:) # タスクが完了してたらコメントは追加できない

非ARなクラスを作る例 # 実装は適当ですが、タスクのリストを扱う場合はこんな概念を検討してみてもいいかもしれない class UserTaskList def initialize(tasks:, user:) @tasks =

app/modelsに非ARなクラスを作るのはRails Wayじゃない？ https://www.youtube.com/watch?v=hkmrfjex7jI&t=3s DHHもやってるっぽいし多分大丈夫！