はじめに
みなさんはWebシステムの3層アーキテクチャ(構造)についてご存じでしょうか？
簡単に説明すると、Webシステムは
- 画面を見せるところ（プレゼンテーション層）
- プロセスを実行するところ（アプリケーション層）
- データを保存するところ（データベース層）
この3層に分けたほうがいいよ！という内容です。
これを最初に学んだ私は
「......そんなこと知ってるよ！というかそれ学んで何になるんだよ！」
という気持ちでした。
しかし本質的にはとても大切な内容が書かれていたのです。
根本には「責務分離」という考え方がある
責務分離というのはなんなのでしょうか？
「一つのことは一つの場所で」
これが責務分離の考え方です。
たとえば、あなたの部屋を想像してみてください。
- 服はクローゼットに
- 食器はキッチンに
- 本は本棚に
もし全部が一つの箱に詰め込まれていたら？何かを探すたびに大変ですよね。
プログラムも同じです。
- 表示するコード
- 計算するコード
- データを保存するコード
これが全部混ざっていたら、修正するときに大変なことになります。
3層アーキテクチャ IN 3層アーキテクチャのマトリョーシカ
Webシステム3層アーキテクチャで責務分離が果たされました。
しかしもう少し近づいて見ると中では様々な処理が行われています。
たとえば、レストランを想像してみてください。
レストラン全体は「ホール」「キッチン」「倉庫」の3つに分かれています。これがWeb3層アーキテクチャです。
でも、キッチンの中をのぞいてみると？
- 食材を切る人
- 火を使って調理する人
- 盛り付けをする人
さらに細かく役割が分かれていますよね。
Webシステムも同じです。「アプリケーション層」という大きなくくりの中でも、実際には「データを受け取る」「計算する」「結果を返す」といった細かい処理が行われています。
これらを責務分離するために、更にアーキテクチャや設計が存在しています。
つまり、3層アーキテクチャの中に更にアーキテクチャがあるのです。
具体例を見てみましょう。
FLOCSS - プレゼンテーション層の責務分離
FLOCSSは、CSSの書き方を整理するための設計手法です。
Webサイトの見た目を作るCSSは、何も考えずに書いていくと「どこに何が書いてあるか分からない」カオス状態になりがちです。
FLOCSSでは、CSSを3つの役割に分けて整理します。
Foundation（土台）
サイト全体に共通する基本的なスタイルです。文字の大きさや余白のリセットなど、「下地」となる部分を担当します。
Layout（配置）
ヘッダー、サイドバー、フッターなど、ページの「大きな枠組み」を担当します。どこに何を配置するかを決める係です。
Object（部品）
ボタン、カード、フォームなど、繰り返し使う「パーツ」を担当します。レゴブロックのように、組み合わせて使える部品を作ります。
こうすることで「このスタイルはどこを見ればいいか」が明確になり、修正や追加がしやすくなります。
MVCモデル - アプリケーション層の責務分離
MVCは、プログラムの処理を3つの役割に分ける設計手法です。
先ほどのレストランの例えに戻りましょう。
Model（モデル）= 食材と調理
データそのものと、データを処理するルールを担当します。レストランでいえば「食材を管理し、レシピ通りに調理する」役割です。
View（ビュー）= 盛り付けとお皿
ユーザーに見せる画面を担当します。「料理を美しく盛り付けて、お客様に提供する」役割です。
Controller（コントローラー）= ホールスタッフ
ユーザーからの指示を受け取り、適切な処理を呼び出す担当です。「お客様の注文を聞いて、キッチンに伝える」役割です。
お客様（ユーザー）は料理（画面）だけを見ますが、裏側では注文係、調理係、盛り付け係がそれぞれの仕事をしているのです。
3層スキーマ - データベース層の責務分離
3層スキーマは、データベースを「誰がどう見るか」で3つに分ける考え方です。
会社の社員情報を例に考えてみましょう。
内部スキーマ = 保存方法
データが実際にどこに、どういう形式で保存されているか。「サーバーAのハードディスクに、こういうファイル形式で入っている」という技術的な話です。普通の利用者はこれを意識しません。
概念スキーマ = データの全体像
「社員番号」「名前」「部署」「給与」「入社日」など、会社として管理している社員情報の全体構造です。どんなデータがあって、それぞれがどう関連しているかを示します。
外部スキーマ = 見せ方
同じ社員情報でも、見る人によって必要な情報は違います。
- 人事部：給与や評価も含めた全情報
- 一般社員：名前と部署と内線番号だけ
- 経理部：給与と口座情報だけ
同じデータでも「保存のしかた」「全体の構造」「見せ方」を分けることで、保存方法を変えても見せ方に影響しない、見せ方を変えても元のデータ構造に影響しない、という柔軟性が生まれます。
アーキテクチャの本質は責務分離である
ここまで見てきたように、様々なモデルや設計がありますが、どのように責務分離を行うか という思想が根本にあります。
| レイヤー | 設計手法 | 何を分けているか |
|---|---|---|
| プレゼンテーション層 | FLOCSS | CSSの役割 |
| アプリケーション層 | MVC | 処理の役割 |
| データベース層 | 3層スキーマ | 誰がどう見るか |
これを理解しないままアーキテクチャを学ぼうと思っても、なかなか頭に入ってきません。
逆に 「責務分離」 の概念を理解しているならば、どのような思想で設計されているのかが分かりやすくなります。
更に言えばこの考え方は、他の言語や技術にも応用が可能です。
例えば「1つのClassには1つだけの機能を持たせるべき」とよく言われています。
これもまさしく責務分離の考え方なのです。
おわりに
「3層アーキテクチャ」「MVC」「FLOCSS」
プログラミングを学んでいると、次々と新しい設計手法やアーキテクチャが出てきて、覚えることが多いと感じるかもしれません。
しかし、今回お伝えしたかったのはこれらは全て「責務分離」という一つの考え方から生まれているということです。
名前や細かいルールは違っても、やりたいことは同じ。
「一つのことは一つの場所で」
これだけです。
新しいアーキテクチャに出会ったら、こう考えてみてください。
「これは何と何を分けようとしているんだろう？」
その答えが見えれば、理解は格段に早くなります。
そして、いつか自分でコードを書くとき、設計を考えるとき、この「責務分離」の視点があなたを助けてくれるはずです。