この記事は何？

　3層アーキテクチャやらMVCモデルやらの概念がピンときていない、Webアプリケーション設計初心者が、これらの概念を整理したものです。Webアプリに限らず、クライアントサーバ方式のアプリであれば参考になるかと思います。　理解が追いついていない部分があるかと思うので、ご指摘・アドバイスお待ちしています。

※下記の記事を参考にしました。
アプリケーションアーキテクチャ理解に必要な“3層構造”　プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割 - ログミーTech

クライアントサーバ方式

　例えばユーザがネットサーフィンしている場合、単純なやりとりは下図のようになる。

　青字で書いた通り、データを要求するクライアントと、データを送るサーバの2つの役割が存在する、クライアントサーバ方式である。クライアントとサーバはそれぞれ役割のことを指すので、ユーザ＝クライアントとは限らない。ただし、Webアプリケーションをつくるときは、基本的にユーザPCのWebブラウザ側がクライアント、記事の持ち主がサーバとなる。Webブラウザ側をフロントエンド、記事の持ち主側をバックエンドと呼ぶこともある。

3層構造

　ここまでで、「記事の持ち主」と言っていたものの正体がWebアプリケーションらしい。Webアプリケーションは基本的に3層構造をもつ(注：この後に出てくる3層アーキテクチャと3層構造は別物)。

Webサーバ…固定の記事の内容をクライアントに渡す役割。記事の内容とは、HTMLファイルやCSSファイル、JSファイルなどのWebページのこと。ここでは処理をしてページを変えることはできないため、処理が必要なアクションがユーザからなされたときはアプリケーションに渡す。
アプリケーション…Webサーバから送られてきたアクションをもとに処理を行い、Webページを生成する。処理の最中にDBからデータを取ってくることがある。
DB…記事の内容を生成するために必要なデータを蓄える。

　昔はこの②～⑦の流れを毎回行っていたが、記事の持ち主に毎度記事更新を持ちかけるのはタイムロスが激しいということで、JavaScriptで書かれたファイル(JSファイル)が流行りだした。JSファイルは、多少の処理と動的なページ変更ができる。例えば、ラジオボタンをクリックしたら黒点が表示されるとか。このJSファイルに書けることがどんどんリッチになってきていて、ユーザPCのWebブラウザ上だけで(すなわち①～⑦をやらずに)結構なインタラクションができるようになってきている。

3層アーキテクチャ

　3層構造のうちアプリケーション部分はさらに3つの機能にわけることができる。3層構造までは、どちらかというとシステムの構成の話をしているが、ここからはアーキテクチャすなわちプログラムの設計思想の話になる。すなわち、これ通りにつくらなくても同じふるまいをするアプリケーションをつくることができる。

プレゼンテーション層…ユーザがどんなアクションをしたか受け取る部分(a)＆ユーザに結果を返す部分(b)。すなわちユーザとやり取りする部分。
ビジネスロジック層…実際の処理を行う部分(c)。プレゼンテーション層とデータアクセス層がやらないことをやると思っておけばOK
データアクセス層…DBに欲しいデータを要求する部分(d)＆DBからデータを受け取る部分(e)。すなわちDBとやり取りする部分。

　図の(a)～(e)の文字順と実行順に関係はない。アクションを受け取ってすぐに記事がつくれるようであれば、(a)→(b)の順で実行されるし、記事をつくるために処理が必要であれば、(a)→(c)→(b)の順で実行される。(c)では何度も(d)を呼び出し(e)を受け取ることもある。
　3層アーキテクチャの良いところは、あとからの変更が容易となること。例えば、ユーザがキーボード操作していたWebアプリをマウス操作に切り替えたいとなったとき、作り変えるのはプレゼンテーション層だけで良い。例えば、DBをSQLからNoSQLに変更したいとなったとき、作り変えるのはデータアクセス層だけで良い。

　ややこしいのが、3層アーキテクチャはあくまで設計思想である。よって、フロントエンドにもプレゼンテーション層が存在することがある。確かに、フロントエンドでもユーザがどんなアクションをしたか受け取る部分(a)とユーザに結果を返す部分(b)は必要だし、これが明確に役割として分離し設計されていたらプレゼンテーション層が存在することになる。さらに、先に述べたように、ユーザPCのWebブラウザ上だけでいろいろできるリッチなWebページも増えてきている。フロントエンドに3層アーキテクチャを適用した設計も見受けられるようになってきている。

MVCモデル

　MVCモデルとは、プログラムの処理をModel、View、Controllerの3種類に分けて考える設計思想のことを指す。3層アーキテクチャとは関係がない、別物の設計思想。ただし、3層アーキテクチャと組み合わせると、下図のようなイメージ。

　MVCモデルの良いところは、オブジェクト指向を突き詰められるところか(あくまで所感)？昔Ruby on Railsを用いたプロジェクトに参加していたことがあるが、ソースコードの可読性が良いというか、それぞれの役割が明確な気がした。3層アーキテクチャと組み合わせると最強になると思う。

具体例

　ここまでの理解を、自分のよく知るアプリケーションに当てはめたい。ということで、散々Webアプリの話をしておいて、Webアプリではない例になってしまうが…。VRChatの設計イメージを記す。※3層構造より深い設計思想の可視化をあきらめた…。

終わりに

　とてもわかりやすい記事があって助かった。初めて深堀りする気が起きた。実際のアプリケーションだとどうなっているのかなとリバースエンジニアリング？することで、概念としてわかっていてもイマイチしっくりこない、という状況を打破できた気がする。
　改めて、理解が追いついていないところが多いかと思うので、ご指摘・アドバイスお待ちしています。