3層クライアントサーバ（役割を3つに分ける構成）

📌

3層クライアントサーバとは

3層クライアントサーバとは、システムの仕事を3つの層に分けて構成する方式のことです。具体的には次の3層に分けます。
・プレゼンテーション層：画面表示と入力を担当（見た目の部分）
・アプリケーション層：業務の処理・判断を担当（中身の処理）
・データ層：データの保管・検索を担当（データベース）

ポイントは「役割ごとに層を独立させる」ことです。各層は隣り合う層とだけやり取りし、それぞれが自分の仕事に専念します。

身近な例で考えると、レストランの分業に似ています。注文を取る接客係（プレゼンテーション層）、料理を作る厨房（アプリケーション層）、食材を保管する倉庫（データ層）が役割分担します。接客係は調理方法を知らなくてよく、厨房は倉庫の整理方法を気にしなくてよい──こうした分業が3層構成の考え方です。

📌

各層の役割

3つの層がそれぞれ何を担当するのかを整理します。色は上の図解と対応しています。

処理の流れは次のようになります。利用者がプレゼンテーション層で操作すると、その要求がアプリケーション層に渡されて業務処理が行われ、必要なデータはデータ層から取り出されます。結果は逆向きに戻され、画面に表示されます。

各層は隣の層とだけやり取りするのが原則です。プレゼンテーション層がデータベースを直接操作することはなく、必ずアプリケーション層を経由します。こうして役割の境界をはっきりさせています。

📌

2層との違い

従来の2層クライアントサーバは、クライアント（画面と業務処理）とサーバ（データ）の2つで構成します。このとき業務ロジックが画面側に混ざってしまうのが弱点でした。

3層では業務ロジックを独立した「アプリケーション層」に切り出します。これによって次のメリットが生まれます。
・影響範囲の局所化：業務ルールを変えてもアプリケーション層だけ直せばよく、画面やデータは触らずに済む
・個別の拡張：処理が重い層だけサーバを増強でき、層ごとに別々に拡張できる
・保守性の向上：役割が分かれているため、どこを直せばよいか分かりやすい

つまり3層は2層の「業務処理が画面に混ざる」問題を、層を1つ増やして解消した構成だといえます。規模が大きく変更の多いシステムほど、この分離の効果が効いてきます。

📌

なぜ層を分けるのか

なぜわざわざ3層に分けるのでしょうか。答えは「変更したとき、どこまで影響が及ぶかを小さくするため」です。

もし画面・処理・データがすべて1か所に混ざっていると、消費税率が変わって計算ロジックを直したとき、画面の表示コードにも影響が出るかもしれません。どこまで直せばよいか追うのが大変です。

3層に分けておくと次のような利点が生まれます。
・変更の影響が层内に留まる：業務ルールを変えるときはアプリケーション層だけ直せばよく、画面やデータ層は触らずに済む
・負荷に合わせてサーバを増やせる：処理が重い層（例：アプリケーション層）のサーバだけ追加して対応できる
・担当チームを分けられる：画面担当・処理担当・データ担当と分業でき、大規模な開発でも混乱しにくい

身近な例で考えると電車の分業に似ています。運転士（プレゼン）・車掌（アプリ）・車両整備（データ）が分業されているからこそ、車掌の担当が変わっても運転士の仕事は変わらない──役割を分ければ変更が波及しません。3層構成は「変更に強いシステム」を作るための工夫です。

📌

データの流れ（リクエストが層を旅する仕組み）

実際の処理では、リクエスト（要求）は上の層から下の層へ順番に渡され、結果は下から上へ順番に戻ってきます。上の図のように「プレゼン → アプリ → データ → アプリ → プレゼン」と層を往復します。

具体的な例として「ユーザーが商品一覧画面を開く操作」を追ってみましょう。
・プレゼンテーション層：ユーザーがボタンをクリック → アプリケーション層へ「商品一覧を取ってきて」と要求する
・アプリケーション層：要求を受けて「どの商品を絞り込むか」などビジネスルール（＝業務で決められた処理のルール）を判断 → データ層へ「商品データをくれ」と要求する
・データ層：データベース（＝データを整理して保管する仕組み）から該当の商品データを取り出し、アプリケーション層へ返す
・その後、逆順に結果が上へ戻り、最終的に画面に一覧が表示される

なぜプレゼンがデータを直接取りに行かないのか。それは「プレゼンテーション層はデータベースの場所や取り方を知らなくてよい」という設計にしているからです。必ずアプリケーション層を経由することで、後でデータベースの種類を変えても画面側のコードは変えなくて済むという強さが生まれます。

📝

練習問題