要約
Layer と Tier の違いは、学び始めたときよりも、むしろ実務の会話で混乱しやすいテーマだと思う。今日は同僚とコーヒーを飲みながらこの話になり、ジュニア開発者が意外とつまずきやすいポイントだと感じたので整理してみた。
短く言えば、Layer は論理的な責務の分離で、Tier は物理的な配置・実行単位の分離に近い。ただし現場ではこの2つの言葉が混ざって使われることも多いので、「今はコード構造の話なのか、配置構造の話なのか」を先に確認したほうが安全だ。
この記事の内容
この記事で扱うこと
コーヒーを飲みながら出た Layer と Tier の話
今日、同僚とコーヒーを飲みながらアーキテクチャの話をしていて、Layer と Tier の話題になった。長く開発している人にとってはなじみのある言葉かもしれない。Presentation Layer、Business Layer、Data Access Layer。2-tier、3-tier、N-tier。どれもよく聞く表現だ。
この記事は、その会話をきっかけに Layer と Tier の違いを実務で混乱しにくい形に整理してみた記録だ。
話しているうちに、ジュニア開発者にとっては思った以上に紛らわしいテーマだと感じた。どちらも日本語では「層」や「階層」と訳されやすく、資料によっては “3-layer architecture” と “3-tier architecture” のような表現が混在する。実務者同士でも、会話の中ではそこまで厳密に分けずに使うことがある。
だからこの記事は、Layer と Tier を試験問題のように暗記するためのものではない。会議やコードレビューで、同じ言葉を使いながら別々の図を思い浮かべないようにするための整理だ。
Layer は論理的な責務分離
Layer は一般的に、ソフトウェア内部を役割と責務で分ける論理的な区分を指す。たとえば次のような分け方だ。
- Presentation Layer: UI、リクエスト/レスポンス、ユーザーに近い部分
- Business Layer または Domain Layer: 業務ルールと中心的な判断
- Data Access Layer: データベースや外部ストレージへのアクセス
この区分は1つのアプリケーション内でも成り立つ。同じサーバー、同じプロセス、同じデプロイ単位に入っていても、責務が分かれていれば Layer と言える。たとえば Spring アプリケーションで Controller、Service、Repository を分けるのは、物理サーバーが3台あるからではなく、コードの責務を分けるためだ。
Layer を見るときは、「どこに配置されているか」よりも「どんな責務を持っているか」を先に見る。
Tier は物理的な配置分離
Tier は一般的に、物理的に分離された実行・配置単位を指すときに使われる。「物理的」といっても、必ずしも別々のサーバー機器という意味ではない。別サーバー、別プロセス、別ネットワーク境界、別デプロイ単位のように、実行時に分かれているかが重要だ。
わかりやすい例は 3-tier 構成だ。
- Client Tier: ブラウザ、モバイルアプリ、デスクトップクライアント
- Application Tier: Webサーバー、WAS、APIサーバー、業務ロジックサーバー
- Data Tier: データベース、ストレージ
Microsoft の N-tier architecture の説明でも、アプリケーションを logical layers と physical tiers に分けて説明している。この表現はかなりわかりやすい。Layer は論理的な層で、Tier は物理的な配置の層だ。
Layer と Tier の違いが混乱しやすい理由
混乱する理由は単純だ。実際のシステムでは Layer と Tier が重なって見えることが多いからだ。
| 観点 | Layer | Tier |
|---|---|---|
| 見るもの | 論理的な責務 | 物理的な実行・配置 |
| 主な質問 | このコードは何を担当するのか | この構成要素はどこで動くのか |
| 例 | Controller, Service, Repository | Browser, API Server, Database |
| 分離の基準 | モジュール、パッケージ、関数呼び出し、責務 | ネットワーク呼び出し、プロセス、サーバー、デプロイ単位 |
| 同じサーバー内でもよいか | 可能 | 通常は別 Tier とは見なしにくい |
Controller、Service、Repository がすべて1つのアプリケーション内にあれば、3-layer 構造とは言える。しかし、それだけで 3-tier とは言いにくい。逆に、ブラウザ、APIサーバー、DBサーバーがネットワーク境界をまたいで分かれていれば、3-tier 構成に近い。その API サーバーの内部には、さらに複数の Layer が存在しうる。
もう1つの理由は、現場で言葉が常に厳密に使われるわけではないことだ。言葉だけで争うより、相手がどんな構成図を思い浮かべているのかを確認するほうがずっと建設的だ。
例で見ると違いがわかりやすい
例1. 1台のサーバーで動く Spring アプリケーション
Controller、Service、Repository がきちんと分かれていて、DBアクセスコードが Repository に集まっているとする。これは Layer 分離ができている例だ。ただし、アプリケーションが1つのサーバープロセスとして動いているなら、配置の観点では1つの Application Tier と見るのが自然だ。
例2. ブラウザ、APIサーバー、データベース
ブラウザが API サーバーを呼び出し、API サーバーが DB にアクセスする。この構成は典型的な 3-tier に近い。Client Tier、Application Tier、Data Tier がネットワーク境界で分かれているからだ。そして API サーバー内部には、Presentation/API Layer、Business Layer、Data Access Layer がまた存在しうる。
例3. 昔の 2-tier クライアント/サーバー
以前は、デスクトッププログラムが DB に直接接続する構成も多かった。Visual Basic、Delphi、PowerBuilder などで作ったクライアントアプリが DB と直接通信する形だ。この場合、Client Tier と Data Tier が直接つながる。業務ロジックがクライアント側に多く入ると、配布、セキュリティ、保守の負担が大きくなる。そのため、中間に Application Tier を置く 3-tier 構成が自然に重要になっていった。
例4. React から Supabase を直接呼ぶと 2-tier なのか
コーヒーを飲みながら実際に議論になったのがこの例だった。React アプリケーションから Supabase を直接呼ぶ場合、それは 2-tier と呼べるのかという話だ。
この質問は、Layer と Tier が混ざりやすい代表例だと思う。ブラウザで動く React アプリがあり、チームが別途バックエンドサーバーを運用せず Supabase API を直接呼ぶなら、配置・実行の観点では Client Tier が Supabase 側の Backend/Data Tier に直接つながる構成に近く見える。従来の 3-tier でいう「自分たちが運用する Application Server Tier」が薄い、または存在しない形だ。
ただし、それはアプリケーション内に Layer がないという意味ではない。React コードの中でも、画面コンポーネント、状態管理、API クライアント、検証やドメイン寄りのロジックを分けられる。これは依然として論理的な Layer 分離だ。つまり Tier の観点では 2-tier に見えても、コードの中には複数の Layer が存在しうる。
また、Supabase を単に「DB」とだけ説明すると少し粗くなる。Supabase は PostgreSQL だけでなく、Auth、Storage、Edge Functions、Realtime、REST/GraphQL の API 層なども提供する。したがって「React が DB に直接つながる」よりも、「React がマネージドなバックエンドプラットフォームを直接呼ぶ」と言ったほうが正確だ。この違いを押さえるだけで議論はかなり整理される。
会議ではこうまとめるのがよさそうだ。「自分たちのサーバーを別に置かず React が Supabase を直接呼ぶので、配置の観点では 2-tier に近い。ただし React 内部のコード構造は別の layer として分けて管理すべきだ。」
実務ではこう言うと伝わりやすい
ジュニア開発者にこの話を説明するときは、用語そのものよりも質問を変えてみるのがよいと感じた。
- Layer の話をしているのか。 それなら責務、役割、コード構造、依存方向を見ている。
- Tier の話をしているのか。 それなら配置場所、プロセス、ネットワーク境界、サーバー構成を見ている。
会議で「うちのサービスは 3-layer です」と言ったとき、ある人は Controller-Service-Repository を思い浮かべ、別の人は Browser-WAS-DB を思い浮かべるかもしれない。そのときに「論理的な layer の話ですか、配置上の tier の話ですか」と一度聞くだけで、会話はかなり明確になる。
個人的には、プロジェクト文書では Layer はコード/責務の構造、Tier は配置/実行の構造と先に定義しておくのがよいと思う。特に新規メンバー向けのオンボーディング文書では、この一文が意外と多くの誤解を減らしてくれる。
まとめ
Layer と Tier はどちらもシステムの「階層」を表す言葉だが、実務で区別するときの観点は違う。Layer は論理的な責務分離で、Tier は物理的な実行・配置の分離だ。
もちろん現実には、この2つの言葉は混ざって使われる。だから「その表現は絶対に間違い」と言うよりも、今は論理構造の話なのか、配置構造の話なのかを確認する習慣のほうが大切だ。今日のコーヒーの会話で改めて感じたのは、こういう基本用語ほど、ジュニアには一度はっきり整理しておくと役に立つということだった。
もし誰かに「3-layer と 3-tier は同じではないのですか」と聞かれたら、こう答えたい。図の上では重なって見えることはあるが、Layer はコードの責務を分ける言葉で、Tier は実行される場所を分ける言葉だ。
参考文献
- Microsoft Azure Architecture Center – N-tier architecture style
- Microsoft .NET Architecture – Common web application architectures
- Martin Fowler – Presentation Domain Data Layering
- Wikipedia – Multitier architecture
韓国語原文：この記事は韓国語版をもとに、日本語読者向けに少し整えたものです。韓国語の原文を読む。韓国語もぜひ応援してください。