女性向けエンジニアスクール
3秒でわかる
複雑な仕組みを役割ごとの段に分け、上下の段とだけやり取りさせる考え方。ネットワークでも設計でも、差し替えを楽にするために使います。
もう少し詳しく
どういうものか
階層とは、大きな仕組みを役割ごとの段に切り、それぞれの段が「すぐ上」と「すぐ下」だけを相手にするように整理した構造です。各段は自分の担当だけを果たし、下の段がどう実現しているかは知りません。
もっとも有名な例がネットワークの階層です。TCP/IP では、アプリケーション層が HTTP を話し、トランスポート層が TCP で届く順番と再送を保証し、インターネット層が IP で経路を決め、リンク層が実際の電気信号を運びます。
なぜ必要か
階層に分けない設計では、通信の暗号化を変えたいだけでアプリ全体を書き直すことになります。段で区切ってあれば、下の段の中身を入れ替えても、上の段は同じ呼び出し方のまま動きます。有線を無線に変えても HTTP のコードを触らなくてよいのは、リンク層が差し替え可能だからです。
具体例
Web アプリのコードも同じ発想で切ります。下は3層に分けた例です。
[ プレゼンテーション層 ] HTTP の<a href="/glossary/http-request" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">リクエスト</a>を受け、<a href="/glossary/json" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">JSON</a> を返す
↓ 呼ぶ
[ ユースケース層 ] 「注文する」などの手続きを組み立てる
↓ 呼ぶ
[ データアクセス層 ] <a href="/glossary/sql" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">SQL</a> を投げて<a href="/glossary/table" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">テーブル</a>を読み書きする矢印は上から下への一方向だけです。データアクセス層が HTTP のことを知り始めた時点で、この構造は崩れています。
つまずきやすいところ
層を作ったつもりで、実は素通しになっている例がよくあります。ユースケース層の関数が SQL の結果をそのまま返すだけなら、上の層は結局テーブルの列名に縛られたままです。層を足したぶん記述は増え、得るものはありません。
ネットワークの学習では、OSI 参照モデルの7層を丸暗記して層番号だけ言えるのに、どこで IP アドレスが付きどこでポート番号が付くかを説明できない、という状態になりがちです。番号ではなく「その層が付け足すヘッダは何か」で覚えると、実際のパケットと結びつきます。
似た用語との違い
| 用語 | 指すもの |
|---|---|
| 階層 | 役割で分けた段そのもの |
| 抽象化 | 下の段の詳細を隠して単純な窓口だけ見せること |
| モジュール | 機能のまとまり。同じ段の中に何個も並ぶ |
階層は縦方向の分け方、モジュールは横方向の分け方です。片方だけでは大きな仕組みは整理しきれず、縦に段を切ったうえで、各段の中を横に分けます。
覚え方
段ごとに封筒を1枚ずつ足していくイメージが近いです。下へ行くほど封筒が増え、受け取り側は上へ行くほど封筒を1枚ずつ開けます。宛先を書いた封筒を開けずに中身だけ差し替えられるのが、階層に分ける利点です。
