MVCがなぜ必要かは分かるが、サービスはなぜ必要なのか

Question

プログラムの話でserviceについての質問です。

一般的にMVCモデルの一連の流れはC→M→Vですが、serviceなるものを作って、C→S→M→Vとしているところがたまにあります。

C→M→Vと書きましたが細かく話すと、CはMからデータを受けとりCがVにデータを渡す。
MがVに渡すわけではないので、厳密には、C→M→C→Vということになります。

C→S→M→Vの場合こうなってます。
CはSを呼び出し、SはMからデータを受けとり形成、その結果を受け取ったCがVにデータを渡す。
なので、C→S→M→S→C→Vになります。

で、このSですが、どういうときに作るべきなのでしょうか？
レビューでたまに「なんでサービス作ってないの？」って言われることがあります。
逆に「なんでサービスなんか作らないといけないんだ」と思うわけであります。

どういうときにサービスが必要かをご教授ください。

Answer 1

CはSを呼び出し、SはMからデータを受けとり形成、その結果を受け取ったCがVにデータを渡す。

なので、C→S→M→S→C→Vになります。

このことから、ここで言っているサービスは、汎用処理を担うサービスクラスではなく、アプリケーションをレイヤ化した時のサービス層のことだと考えます。
サービスという言葉は曖昧で、ここは混在されがちなので、まずここはレビューされる方と共通認識を持たれたほうが良いかと思います。

で、このSですが、どういうときに作るべきなのでしょうか？

サービス層の前提で記載しますが、大規模な業務アプリケーション（例えば銀行のシステム等）を開発する時はだいたいこの層を設けます。
理由は大規模な業務アプリケーションだけに業務ロジックが複雑だからです。
各層の役割を明確にし、単一の責任を持たせ、見通して良くして保守性や可読性を向上させる目的があります。
上記の目的から、このサービス層を設ける時は、業務データへのアクセスにリポジトリというデータアクセスにフォーカスした層を設けるのが一般的です。また、この時ModelはEntityと呼ばれることがあります。
Service、Model、Repositoryはアプリケーションのコアとなる層であり、システムの実体や関連性（ビジネス）を表現することから、これらをまとめてドメイン層と呼ばれることがあります。

この時各層の責任分界点はプロジェクトによって異なりますが、だいたい以下のようになります。

Controller

• リクエストのルーティング

　→フレームワークでRoutingサービスに委譲することが多い

• リクエストデータに対する単項目や相関項目チェック

　→フレームワークでValidationサービスに委譲することが多い

• セッション管理
• リクエストをServiceに適切な状態（Model、Entity等）に変換する処理
• 処理結果をViewに適切な状態に変換する処理

　→Controllerをより薄くするためにPresenterに委譲することもある

Service

• ビジネスルールに関わる処理

　→例えばECで言うと、在庫がないと注文を確定できない等、ビジネスルールに即して注文確定させるような主処理

Repository

• 業務データへのアクセス

---

ざっくりな分類ですが、上記を見て、Controllerの役割が多いことにお気づきでしょうか。
本来、Controllerで行うべき多くの処理をフレームワークが各サービス（ここで言っているサービスはサービス層ではない方）に委譲してくれているので、フレームワークを利用するとControllerでやるべきことが少なくなります。
故に、フレームワークを使って、比較的小規模なアプリケーションや業務ロジックがそこまで複雑でないアプリケーションを作る時は、わざわざ新しい層を作るのが面倒なので、この薄くなったControllerに大半の処理を書く人が多いのかと思います。

大規模な業務アプリケーションで利用する言語（Java等）では、言語の特性やフレームワークによるサポートによってアプリケーションのレイヤ化がしやすくなっていますが、PHPもそれに近づいてきていると実感しています。
実際にPHPを代表するSymfonyフレームワークでも、Javaの仕組みをPHPに適応させることでPHPをより良くしていくと言っています。

昨今の変化が激しい時代に、長い目で見て変更に強いアプリケーションを作るのであれば、上記の様にサービスを設けてドメイン層を切り出すというアプローチを取るのも良いかと思います。
ただ、考え方を見直したり、作成するクラス数も増加しますので、検討が必要です。
大事なのは、先人たちが考え出した様々アーキテクチャ（DDD, Clean Architecture, MVVM等）を知って、開発するシステムの特性によってアーキテクチャ使いわけることが重要だと考えます。

Answer 2

「なんでサービスなんか作らないといけないんだ」をレビュワーに確認してはいかがでしょうか。
プロジェクトによりコーディングの規約なども違います。
そのレビュワーはプロジェクトの規約や主旨を理解した上で「なんでサービス作ってないの？」という指摘をしているのでは、と思います。
必要ないと思うのであればそのレビュワーときちんと相談した上で方針を決めるべきです。

一般的な意見で良ければ、下記の質問（stackoverflow）などが参考になるかと。

• MVCモデルにおけるサービスの役割について教えて下さい

Comments

[earnest_gay]

レビュワーに聞いているのですが、「なぜ必要だと思いますか？」とハッキリしたこと言わないのです。
成長を狙って言ってるのか分かりませんが、「そんなのいいからはよ教えてくれｗ」という感じです、、、

リンク先拝見しました。

レビュワーの意図としては、多分、データ形成するならサービス作りましょうってことなんだと思います。
fuelphpを使っているのですが、fuelphpにはpresenterという層があるので（プロジェクトではpresenterを使っていませんがｗ）多分、このpresenterがサービスと同等の役割をするのだと思います。

fuelphpではC→M→C→P→Vという流れになっているので
プロジェクトではC→S→M→S→C→Vのところ、デフォルトのfuelphpに変換するなら
C→M→C→P→Vになるんだと思います。

しかしながら、Vの手前の層はなにもせずにVにデータを渡すだけと考えると
C→M→C→P（データ形成）→V、ではなく
C→M→C（データ形成）→P（Vに渡すだけ）→V、にすべきかなとも思いました。

そして、Cはコントローラーでありながらもサービスと同じ役割も果たしているのと、PがCと同じような役割になっているのが気持ち悪いので最終的に

C→S→M→S→C→P→V、というカオスな構造に辿り着きました。
P、、、いらんｗ

[m.ts10806]

それならやはり「なぜサービスが必要ではないか」という理由を考えるのではなく、
「今遂行しているプロジェクト上、なぜサービスが必要か、レビュワーが求めるサービスとはなにか」を考えて、調べた結果・考え付いた結果をレビュワーに報告し、認識が合っているかを確認するのが一番だと思います。
コメントにも書かれているように、フレームワークによっても「サービス」に相当するものが違うように、プロジェクトによっても違います。
それだけ多種多様な解釈ができるとも言えます。

[momon-ga]

「なぜサービスが必要ではないか」と「なぜサービスが必要なのか」は、根源の部分では同じ理由(コストメリット)になるかと思います。で、質問者さんと担当の方は、そこの考え方に違いがあるんじゃないかと。

[m.ts10806]

これで本当に解決したのか疑問ですね。