私は長い間MVCを使用していて、「サービス」レイヤー（たとえば、Java Webプロジェクト）について聞いていましたが、多くの情報が見つからないため、それが実際のアーキテクチャパターンであるかどうか疑問に思っていました。それ。
MVCSの考え方は、コントローラーとモデルの間にサービスレイヤーを配置して、コントローラー内に存在する可能性のあるすべてのビジネスロジックをカプセル化することです。そうすれば、コントローラーは実行を転送および制御するためだけに存在します。また、コードを複製することなく、多くのコントローラー（WebサイトやWebサービスなど）でサービスを呼び出すことができます。
サービスレイヤーはさまざまな方法で解釈できますが、通常はコアビジネス処理ロジックがあり、MVCアーキテクチャの下、データアクセスアーキテクチャの上にあります。
たとえば、完全なシステムのレイヤーは次のようになります。
その場合、サービス層は次の責任を負います。
MVCで使用するモデルは、サービスからのものである場合とそうでない場合があります。サービスから得られる結果を取得して、メディアに固有のモデル（Webページなど）に操作することをお勧めします。
私は他の場所でこれへの参照を見ることなく自分でこのパターンを考えていて、Googleを検索してここであなたの質問を見つけました:)
今日でも、について話したり投稿したりする団体はあまりありません。
ビューコントローラサービスパターン。
他の人も同じことを考えていることをあなたに知らせるために考えました、そして上の画像は私がそれがどうあるべきかをどのように見ているかです。
現在、現在取り組んでいるプロジェクトで使用しています。
私はそれをモジュールに入れており、上の画像の各レイヤーには独自の自己完結型モジュールがあります。
サービス層は「コネクタ」「仲介者」「サーバー側コントローラ」であり、「クライアント」側コントローラがクライアントに対して行うこと、「サービス」がサーバーに対して行うことです。
言い換えると、クライアント側の「コントローラー」は、サーバー側コントローラーとも呼ばれる「サービス」とのみ「通信」します。
コントローラ---><-----サービスレイヤーからの要求と受信
サービスレイヤーは、情報を取得するか、それを必要とするサーバー側のレイヤーに情報を提供します。
サービス自体は何もしませんが、サーバーレイヤーを必要なものに接続します。
コードサンプルは次のとおりです。
私は何年もMVCSパターンを使用してきましたが、Webで確実な情報を見つけることができなかったため、他の誰かが使用していることを知りませんでした。よろしければ本能的に使い始めましたが、Laravelプロジェクトにがっかりすることはありません。特にビジネスロジックが絶えず変化するアジャイル環境で作業する場合は、中規模のプロジェクトに対して非常に保守しやすいソリューションだと思います。関心の分離があると非常に便利です。
そういえば、小さなプロジェクトやプロトタイプなどにはサービスレイヤーは不要だと思いました。プロトタイプを作成するときにプロジェクトを複雑にしすぎるという間違いを犯しました。それは、最終的には、アイデアを引き出すのに時間がかかることを意味します。プロジェクトを中期的に維持することを真剣に考えているなら、MVCSは完璧なソリューションIMOです。