アプリケーションアーキテクチャ理解に必要な“3層構造”　プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割

本セッションにおける「3層アーキテクチャ」の定義

大嶋勇樹氏：ということで、ここまでで「そもそもアプリケーションアーキテクチャとは何でしょう」という話をしました。ここからが本題的なところで、まず最も基本、最も基本というのは僕の意見ですが、3層アーキテクチャについて話していこうと思います。なにか気になる点があれば、Q&Aに気軽に（質問して）もらえればそちらも回答します。

では、3層アーキテクチャについてに入っていこうと思います。3層アーキテクチャと言われた時に想像するものは、少なくとも私の場合は2つあります。

（スライドを示して）けっこう多くの方がこの2つを思い浮かべるんじゃないかと思います。1つはWebアプリケーションの3層構造と言われるもので、もう1つはアプリケーションの中の3層アーキテクチャというものです。

まずWebアプリケーションの3層構造について、Webアプリケーションは、Webサーバとアプリケーション、アプリケーションサーバと言うこともありますが、Webサーバーとアプリケーションとデータベースの3つから成り立つ3層構造が基本構成と言われています。（スライドを示して）こちらの図に書いている感じですね。

この3層構造を3層アーキテクチャと呼ぶこともあります。どういう役割分担になっているかというと、Webサーバーが固定のHTMLやCSS、JavaScriptを返して、プログラムによる処理が必要だったら、Webサーバーはアプリケーションに依頼します。

アプリケーションは、依頼を受けつけたらプログラムで、HTMLやJSONを生成して返します。データベースはその時に読み書きしたりします。そういった3層構造を3層アーキテクチャということがあります。

（スライドを示して）一方で、アプリケーションの中を3層に分けて整理することがあります。これも3層アーキテクチャと呼ぶことがあります。Webの3層構造でいうところの、真ん中にあるRailsなりLaravelなりSpringなり、なんでもいいですが、そういうアプリケーションの中のコードを3層に分けて整理するようなことがあります。これを3層アーキテクチャと呼ぶこともあります。

ここから3層アーキテクチャと言った時は、Webの3層構造ではなくて、後者のアプリケーションの中を3層に分けた3層アーキテクチャについて話していきます。

3層アーキテクチャそれぞれの役割

（スライドを示して）この3層アーキテクチャですが、プレゼンテーション層、ビジネスロジック層、データアクセス層という3つに分類するものです。

役割を整理してみると、まずプレゼンテーション層はアプリケーションの利用者、アプリケーションの利用者というのは、人間であれば別のプログラムのこともありますが、（その）アプリケーションの利用者とのやりとりをするのが役割です

そしてデータアクセス層は、データベースやファイルといった、データの保存先とやりとりするのが役割です。

ビジネスロジック層は、ビジネスロジックを実装するところです。ビジネスロジックという言葉の意味は後でしっかり説明しようと思うので、まずはプレゼンテーション層と、データアクセス層について、もう少し役割を詳しく見ていこうと思います。

データアクセス層は「データ保存場所に対して読み書きをする」役割

（スライドを示して）データアクセス層は、ファイルやデータベースなど、データを保存するところに対してデータを読み書きするのが役割です。

ビジネスロジックとデータアクセスを分ける、切り離すというのは、保存先がRDBなのか、その他のDBなのか。NoSQLなのか、ファイルなのかわかりませんが、ビジネスロジック層はそれを気にかけないように実装するようなことを言います。

よく見かける方式だと、データアクセス層は「データベースのテーブルと1対1対応した読み書き用のクラスを作るTable Data Gatewayパターン」、Java界隈だと「DAOパターン」と言ったりしますが、こういう実装方式はよく見かけます。

データベースのテーブルに対応したselect、insert、update、deleteみたいなメソッドを持ったクラスを作って、そこにデータベースのテーブルと対応したデータの入れ物クラスとかを受け渡して使うみたいな。そういうのはよく見る実装方式の一種ですね。データアクセス層については、なんとなくイメージがつきやすい気がします。

プレゼンテーション層のアーキテクチャで有名なMVCについて

次にプレゼンテーション層について見てみようと思います。プレゼンテーション層で登場するすごく有名なアーキテクチャがMVC（Model、View、Controller）です。

（スライドを示して）「MVCと3層アーキテクチャはどう対応するんだ」みたいな話がしばしばあると思いますが、それをやってみた図がこんな感じです。3層アーキテクチャは、プレゼンテーション、ビジネスロジック、データアクセスとアプリケーションを分類しています。

MVCはその中でもプレゼンテーション層周辺に注目して、プレゼンテーション層の中をControllerという入力を受けつけたりするものと、見た目、UIを保持するViewに分けています。ビジネスロジックやデータアクセスについては、別途Modelというところに実装しましょうというものです。

ただ、私もいろいろ調べてみたのですが、MVCは歴史の中でどんどん派生形が出てきていて、Modelという概念自体は相当曖昧な感じですね。

なのでMVCといった時、「Controllerという入力を受けつけるところがあって、ViewというUIを担うところがあって、ほかをなんとなくModelと呼んでMVCと言ってしまっている」ということがけっこうあります。

MVCはざっくり「プレゼンテーション層のアーキテクチャですよ」というところを押さえてもらえればいいかなと思います。

プレゼンテーション層は「アプリケーションの利用者とやりとりする」役割

「じゃあプレゼンテーション層ってそもそも何？」（ということ）についてもう少しだけ深掘りしようと思います。プレゼンテーション層は、アプリケーションの利用者、利用者は人間だったり別のプログラムのこともありますが、その利用者とやりとりする層です。

（スライドを示して）例えば、以下のようなものがプレゼンテーション層になります。3種類挙げています。1つはいわゆるMVCなどで実装するような、HTMLを返すWebアプリケーションやリクエストを受け取るController、UIを担うViewあたりが、プレゼンテーション層の役割を持っています。

もしJSONなどを返すWebアプリケーション、Web APIみたいなものであれば、APIの受付だったりレスポンスを返したりする出入口のControllerだったり、リクエストとかレスポンスの型がプレゼンテーション層に属します。

ほかにも、例えばコマンドラインアプリみたいなものであれば、コマンド標準入力からのユーザーの入力の受付や、処理結果を標準出力に出すとかはプレゼンテーション層の役割ですね。

よくプレゼンテーション層はフロントエンドのことだと勘違いされることがあるので、ちょっとその点を補足しようと思います。

（スライドを示して）フロントエンドとプレゼンテーション層は別の概念です。フロントエンドはブラウザなど、ユーザーの手元で処理されるものをいいます。Webアプリみたいなものであれば、HTML、CSS、ブラウザ上で動くJavaScriptなどが該当します。モバイルアプリであれば、モバイルアプリを手元にインストールして使うので、フロントエンドと言うこともできます。

一方、サーバーサイド（のプレゼンテーション層）は、通信した先のサーバー上で処理されるもののことを言います。言語としてはRubyやPHP、Java、Python、Go、JavaScriptなどがありますが、いろいろな言語で実装されるところですね。

これまで出してきたプレゼンテーション層、ビジネスロジック層、データアクセス層は、今までの例でいうと、サーバーサイドの中をプレゼンテーション層、ビジネスロジック、データアクセス層に分類できるという話です。

今、サーバーサイドの中と言いましたが、フロントエンドも特に最近はけっこうコード量が多いと思います。フロントエンドの中のコードをこういった3層に分けることも、それはそれでできます。

Webアプリの場合は、フロントエンドをこういう3層アーキテクチャみたいな感じで分けて実装することはあまり聞きませんが、例えばモバイルアプリではわりとそれに近いことをやっている例もけっこう耳にするかなと思います。

この3層に分けるのは別にサーバーサイドに限ったことではなくて、ほかの、特にモバイルアプリでもよく言われる議論ですが、そういうところでも使える話にはなっています。

プレゼンテーション層とフロントエンドの違い

ちょっと話を戻して、プレゼンテーション層とフロントエンドがなぜややこしいかです。フロントエンドはブラウザなどのユーザーの手元で処理されるもので、プレゼンテーション層は今の例だと、サーバーサイドの中でも一番入口にいるものを指しています。

Webアプリの場合、プレゼンテーション層でHTMLを生成する場合があります。例えばRailsでERBを使った、LaravelでBladeを使った、SpringでThymeleafを使った場合、サーバーサイドでHTMLを生成したりすることになります。そういう時は「このプレゼンテーション層はフロントエンドでもある」と言うこともできるかなとは思います。ブラウザ上で処理されるHTMLを生成しているので、ある意味フロントエンドかなと。

ただ、例えばAPI方式のアプリケーションであれば、プレゼンテーション層には特にHTMLは出てきませんが、ブラウザ上のJavaScriptから通信される。その入口のAPIの口をプレゼンテーション層と呼んだりする。そんな感じですね。ということで「プレゼンテーション層とフロントエンドは別ですよ」というところを補足しました。

3層アーキテクチャの役割分担まとめ

（スライドを示して）ということであらためて整理すると、3層アーキテクチャはこういう分担になります。まずプレゼンテーション層にアプリケーションの利用者、人間だったり別のプログラム、これは例えばブラウザ上のJavaScriptから通信してくるとか、どこかにAPIとして公開しておいて関係ないプログラムから通信されるとか、そういうことを想定している。そういう入口の層があります。

もう1つ、データベースやファイルなど、データの保存先とやりとりするデータアクセス層というのがあります。

そして、その間にビジネスロジックを実装するビジネスロジック層があります。これが3層アーキテクチャというもので、アプリケーション設計の中で個人的にこれが一番基本の考え方かなと思っています。

（次回に続く）