こんにちは！
先日記載させていただいた、「MVCについて軽く触れる」の次は、MVCに”Service”の役割を追加したMVCSについて触れようと思います。
MVCがわからない方がいれば、先にこちらを読んだ方がわかりやすいかと思います。->「MVCについて軽く触れる」

MVCSとは、前回記載した「MVCについて軽く触れる」で触れた「MVC」にServiceという役割を追加したアーキテクチャの事を指します。そもそも「MVCS」という言葉自体はないのですが、時々このようなワードで耳にすることがあるため、今回は「MVCS」という名前を用いて紹介しますね。

まず、MVCについては「MVCについて軽く触れる」でも触れている通り “No, Fat Controller, Yes, Fat Model.” というのが基本です。

しかしModelに業務ロジックを記述すると、大きなシステムを作成する際に「Modelが肥大化して苦しい問題」に発展します。

そこで「MVC」にServiceという役割を追加した「MVCS」が登場したようです。

Model、View、Controller、Serviceのそれぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に以下に表しています。

・Model: リソースへの接続を担当する。
・View: 表示、入出力の処理を担当する。
・Controller: ServiceとViewの制御を担当する。
・Service: ControllerとModelの間でビジネスロジックを担当する。

MVCとMVCSとの大きな違いは、文字の通りServiceがあるかないかです。

MVCのModelでは、データへの接続とビジネスロジックを担当していました。しかし、MVCSのModelはデータへの接続のみになり、Serviceでビジネスロジックを担当することになります。ここが明確な違いです。

前のMVCの図に上書きすると、この位置にServiceが来ます。

・MVCSのServiceは、MVCのModelの肥大化を防ぐための新たな担当。

・MVCのModelでは、データへの接続とビジネスロジックを担当していたが、MVCSのModelはデータへの接続のみ、Serviceでビジネスロジックを担当する。

MVCを実装した方は是非、ModelとServiceを分けて実装してみると、アーキテクチャってこうやって役割分担されていくのか、、、という事がわかりやすいかなと思います。

アーキテクチャというのは問題解決の一つの策だと思います。今回のMVCSも、MVCに問題があったからServiceを増やそうぜ！となったわけです。

他の色々なアーキテクチャも色々調べていると、何かしらの問題解決のために出来上がる事がわかってくると思います。