レイヤードアーキテクチャ

作成: 2026.03.24更新: 2026.03.24

レイヤードアーキテクチャとは

レイヤードアーキテクチャ（Layered Architecture）は、アプリケーションを複数の「層（レイヤー）」に分割し、各層に明確な責務を持たせるアーキテクチャパターンである。上位層が下位層を呼び出す一方向の依存関係を原則とし、各層の独立性を高めることで、変更の影響範囲を限定し、保守性を向上させる。

最も一般的な構成は 3 層アーキテクチャ（プレゼンテーション層・ビジネスロジック層・データアクセス層）であり、SIer の業務システム開発で標準的に採用されている。

なぜ SIer で重要か

SIer の開発プロジェクトでは、数十人から数百人規模のチームが一つのシステムを開発することがある。レイヤードアーキテクチャを採用することで、担当する層ごとに作業を分担しやすくなり、大規模開発の効率化につながる。

また、NTT データが公開している TERASOLUNA（テラソルナ）開発ガイドラインでもレイヤードアーキテクチャが推奨されており、この構成を前提とした設計書やコーディング規約が多くのプロジェクトで採用されている。レイヤードアーキテクチャを理解しておくことは、SIer の設計書を読み解く上で欠かせない。

基本概念

3 層アーキテクチャの各層

┌──────────────────────────┐
│  プレゼンテーション層     │  画面表示・ユーザー入力の受付
│  （Presentation Layer）  │
├──────────────────────────┤
│  ビジネスロジック層       │  業務ルール・データ加工
│  （Business Logic Layer）│
├──────────────────────────┤
│  データアクセス層         │  DB との読み書き
│  （Data Access Layer）   │
└──────────────────────────┘

プレゼンテーション層

ユーザーインターフェースを担当する層。HTTP リクエストの受け取り、入力値のバリデーション、画面の描画を行う。MVC パターンの Controller と View がここに該当する。

ビジネスロジック層

業務ロジックを担当する層。注文処理、金額計算、在庫チェックなど、アプリケーション固有のビジネスルールを実装する。Service クラスとして実装されることが多い。

データアクセス層

データベースとの通信を担当する層。SQL の発行、データの取得・更新を行う。DAO（Data Access Object）や Repository パターンで実装される。

依存の方向

レイヤードアーキテクチャの重要な原則は、上位層から下位層への一方向の依存 である。

プレゼンテーション層 → ビジネスロジック層 → データアクセス層
（上位）                                    （下位）

プレゼンテーション層はビジネスロジック層を呼び出してよい
ビジネスロジック層はデータアクセス層を呼び出してよい
逆方向の呼び出し（下位から上位）は禁止

この原則を守ることで、下位層を変更しても上位層への影響を最小限に抑えられる。例えば、データベースを Oracle から PostgreSQL に変更する場合、データアクセス層のみの修正で済む。

SIer での使われ方

Spring Framework での実装

SIer の Java 開発で最も一般的なレイヤー構成は以下の通りである。

レイヤー	Spring での実装	アノテーション
プレゼンテーション層	Controller クラス	`@Controller`
ビジネスロジック層	Service クラス	`@Service`
データアクセス層	Repository / DAO クラス	`@Repository`

各層の間でデータを受け渡す際には、DTO（Data Transfer Object） や Entity クラスを使用する。

TERASOLUNA での推奨構成

TERASOLUNA 開発ガイドラインでは、3 層にさらに細かい役割を追加した構成が推奨されている。

Controller → Helper → Service → Repository → MyBatis Mapper

Helper はプレゼンテーション層とビジネスロジック層の間でデータ変換を行う役割を担う。このように、基本の 3 層をベースにプロジェクトの規模や要件に合わせてカスタマイズすることが一般的である。

パッケージ構成の例

SIer のプロジェクトでは、レイヤーごとにパッケージを分けることが多い。

com.example.project
├── controller/    ← プレゼンテーション層
├── service/       ← ビジネスロジック層
├── repository/    ← データアクセス層
├── entity/        ← DB テーブルに対応するクラス
└── dto/           ← 層間のデータ受け渡し用クラス

よくある問題

Service 層が肥大化する --- すべてのビジネスロジックを 1 つの Service クラスに詰め込んでしまい、数千行のクラスになってしまう。適切な粒度で Service を分割することが重要。
層をスキップする --- Controller から直接 Repository を呼び出してしまう。ビジネスロジックが不要に見える場合でも、Service 層を経由するルールを守ることで、後からロジック追加が容易になる。

まとめ

レイヤードアーキテクチャはアプリケーションを複数の層に分離する設計パターンである
3 層構成（プレゼンテーション / ビジネスロジック / データアクセス）が SIer では標準的
上位層から下位層への一方向の依存を原則とする
TERASOLUNA でも推奨されており、Spring Framework のアノテーションと対応する
大規模チーム開発での作業分担と保守性の向上に貢献する