Service Objectがアンチパターンである理由とよりよい代替手段（翻訳）｜TechRacho by BPS株式会社

近年、RailsアプリにService Objectを追加するメリットを説く記事が次から次へと量産されています。私は本記事において、それがなぜ正しくないかを述べたいと思う次第であります。もっとよい方法はあるのです。 私はこれまで、Service Objectに関するネット上の議論にときおり参加しては、問題に対するまっとうな解決方法としてService Objectが正しくない理由について繰り返し見解を述べてきました。実際、私は多くの場合においてService Objectよりもっとよい解決方法があると考えるのみならず、Service Objectはオブジェクト指向設計原則への配慮が損なわれている兆候を示すアンチパターンとして取り扱っています。 このような深遠なポイントを細切れのツイートやコメント欄を追って理解するのは大変です。そこで私は、私の見解を正確に表すいくつかの現実的なコードを詳しく

[bayashi_net]

どっちでもスパゲティ感は免れない気がするんだけど、というのはさておき、現実にはservice objectで書く人とモデルに書く人と現れてさらにカオスでしょうね。知らんけど

[turanukimaru]

Serviceは「この処理をする"何か"がないと落ち着かないから取り敢えず作ってServiceと名前を付けてる」だけなのでなくせとは言わないが不要。例えばService(x)は必ずx.do() にできる。そして引数も返値もないServiceは存在しない

[hitode909]

パターンが、シンプルなものから複雑なものまでほぼ無限に、ほぼあらゆる種類のプログラミングスタイルを無節操に許容して促進するのであれば、そんなものは開発者にとって最早有用なパターンでも何でもありません。

[j5ik2o]

蛇足だけど、一貫性のないトランザクション境界を持つ、モデルとサービスメソッドの組み合わせが、ロック競合の温床になりやすいというのもある。まぁ、DDDの集約がわかってたら比較的コントロールしやすい思うけど。

[gnety]

1つの問題を解決しようとして２つの問題を生み出すみたいな話にも見える

[masatomo-m]

社内でもレビューが盛り上がりました。ところでconcernに切り出しただけでは結局fat modelなのではと思うんですが、どうなんでしょう？自分はconcernに分割するよりcompositeして分けた方が好みです

[Tomato-360]

concernに置くのは堂なんだろうな。

[lalala360]

コントローラにビジネスロジックをだらだら書く、という最低最悪パターンから抜けるために、とりあえずビジネスロジックを切り出して置く場所が必要だったのです。

[w1234567]

分厚いサービスレイヤーが間違いなだけでその下が適切に分割されてドメインオブジェクトが用意されていれば、サービスオブジェクトも悪じゃないと思ってるよ

[iga_k]

めっちゃわかる 「ここで問題なのは、ルールを強制するものが何もないということです。これっぽっちもないんです！」

[odakaho]

共通処理をどこに置くかみたいな話にならん？

[Eiichiro]

一つ前の記事と趣旨は同じ。代替手段にPOROと書いてるし、件の記事でもrunやcallにまとめず、クラスメソッドで書かないservice classを推奨しているので。POROで書かれたドメインロジックをなんと呼ぶか？それが問題。

[nakag0711]

実質的なメソッドが一つだけで、しかもそれを一回しか呼ばないようなクラスができた時は何かが間違っていると疑うべき。大抵の解はフリー関数又は静的メソッドだけど、Rubyは知らん

[nunulk]

"本質的には関数であるものがぎっしり詰まったapp/servicesフォルダを見て心が折れるくらいなら、"

[youko03]

つまりfat modelは大体POROになるような。主張はこれと同じ？ > https://qiita.com/joker1007/items/25de535cd8bb2857a685

[Dai_Kamijo]

Service Objectがアンチパターンである理由とよりよい代替手段 — BEAR.Sunday (@BEARSunday) September 1, 2018 from Twitter https://twitter.com/Dai_Kamijo September 03, 2018 at 09:55AM via IFTTT

[daaaaaai]

concern+poro、いいと思うけれど、だれがporoをさわるかとかどこにおくかとか曖昧になる・・・。DDDに沿ったrailsひながたっぽいの見てみたい

[efcl]

サービスオブジェクトパターンについて

[himanoa]

みんながconcern嫌いで安心した

[YaSuYuKi]

Javaでも、Springあたりでは非常によく似た問題がある。このへんの階層化を強制するようなフレームワークは私の知識にはないが、実例はあるのだろうか

[sylvan_l]

Service Objectがアンチパターンである理由とよりよい代替手段（翻訳）

[overleo]

わかる。

[rryu]

まあ、サービスにするのは処理の起点が1個のオブジェクトではない時とかで、そうでないならRails的にはメソッドにした方が素直ではある。

[ghostbass]

「サービスという名のトランザクションスクリプト」問題は抱えているがドメインモデルに移行できない

[assaulter]

Railsお勉強中

[toru_iwashita]

“ルールを強制するものが何もないということです。” Railsで使う時はこれにすごく同意だけど、ロジックを徹底的にモデルに寄せて、一貫性をもってServiceを使えば良い気がする。

[castaneai]

“Service Objectはアカンやつであり、ほとんどの場合もっとよいソリューションがあります。どうかそちらをお使いください”

[hamichamp]

悩ましいね

[bellking]

“を今皆さまが見ているわけですが、問題はこのコードが実際より相当簡略化されたものだという点です。コードベース内の実際のコードは74行ものスパゲッティコードになっていて、メソッドが別のメソッドを呼び、それ

[hisaju]

これ社内でも議論したいな。僕もロジックを寄せるだけのServiceObjectは好きじゃないし