はじめに
アプリケーション開発において「レイヤードアーキテクチャ」は長年にわたり利用され続けている最も基本的なアーキテクチャパターンのひとつです。本記事では、レイヤードアーキテクチャの概要からメリット・デメリット、さらに実用的なディレクトリ構成例までわかりやすく紹介します。
🧱 レイヤードアーキテクチャとは？
レイヤードアーキテクチャ（Layered Architecture）とは、アプリケーションを複数の「層（Layer）」に分割し、役割ごとに責務を分離した構造のことです。
一般的には以下の4層構成がよく使われます。
-
Presentation Layer（プレゼンテーション層）
UI や API エンドポイントなど「外部と接する部分」を担当。 -
Application Layer（アプリケーション層）
ユースケース（アプリの操作の単位）を実行し、ドメイン層を調整する。 -
Domain Layer（ドメイン層）
ビジネスルールやドメインロジックを定義する中核部分。 -
Infrastructure Layer（インフラ層）
DB・外部API・メッセージングなど外部システムとつながる部分。
依存方向は上位 → 下位のみ とし、責務を明確化することが特徴です。
🤔 なぜ必要なのか？
アプリケーションが複雑になるほど、機能追加や修正の影響範囲が広がり、保守性が低下します。
レイヤードアーキテクチャが必要とされる理由は、主に以下の点にあります。
-
関心の分離（Separation of Concerns）
UI とビジネスロジック、DB アクセスを明確に分離することで可読性と保守性が向上。 -
変更に強い構造を作れる
UI を変更してもドメインロジックが影響を受けないなど、変更の影響が局所化される。 -
テストしやすい
ドメイン層を独立させることで、外部依存のないロジック単体のテストが容易に。 -
役割と責任の明確化
設計段階での認識合わせがしやすく、チーム開発が効率化。
👍 レイヤードアーキテクチャのメリット
1. 保守性が高い
責務が分離されているため、どこを変更すべきか判断しやすい。
2. テスト容易性が高い
特にドメイン層が外部依存を持たないためユニットテストが書きやすい。
3. 再利用性が高まる
アプリケーション層・ドメイン層は UI に依存しないため、複数の UI（Web / Mobile / CLI）で使い回せる。
4. チーム開発がしやすい
役割分担が明確になり、衝突の少ない開発が可能。
👎 レイヤードアーキテクチャのデメリット
1. コード量が増える
レイヤー分割によりクラスやディレクトリが多くなりがち。
2. 開発スピードが遅く感じることがある
小規模プロジェクトでは「階層構造はやりすぎ」になることも。
3. 依存方向の制約が煩わしい場合がある
柔軟性よりも規律を優先するため、設計が堅くなりがち。
4. 横断的な処理が実装しづらい
ログやバリデーションなど、複数層に関わる処理の整理が課題となる。
🛠 レイヤードアーキテクチャの実用例（ディレクトリ構成）
ここではバックエンドアプリ（TypeScript or Java/Kotlin を想定）の一般的な構成例を紹介します。
📁 例1：典型的な4層構造
src/
presentation/
controllers/
request/
response/
application/
usecases/
services/
domain/
models/
repositories/
domain_services/
infrastructure/
database/
prisma/
mysql/
external/
repositoryimpl/
層ごとの役割
| Layer | 役割 |
|---|---|
| presentation | Controller などの外部からの入力を受け付ける層 |
| application | ユースケースを扱い、ドメインを調整する |
| domain | ビジネスロジックの中心（アプリの本質） |
| infrastructure | DB や外部APIとの連携 |
🧩 もう少し具体例：ユースケースの流れ
例：ユーザーを新規登録する処理
Presentation
└ Controller でリクエストを受け取る
Application
└ CreateUserUseCase を実行
Domain
└ User エンティティを生成し、ドメインルールをチェック
Infrastructure
└ UserRepositoryImpl が DB に保存
流れの見える化
[Controller] → [UseCase] → [Domain Model] → [Repository] → [DB]
📌 まとめ
レイヤードアーキテクチャは、アプリ開発における「最も基本で、最も普遍的な」アーキテクチャパターンです。
- 責務を分離することで保守性・テスト性が向上
- チーム開発でも認識合わせしやすい
- 大規模開発に特に効果を発揮
- 一方で階層が多く、初期コストは大きくなる
小規模〜中規模でも応用できるため、
「とりあえず基本を固めたい」 という人におすすめのアーキテクチャと言えるでしょう。
レイヤードアーキテクチャの種類については以下を参考にしてください。
https://qiita.com/mshr_n17/items/331424b13f5d7156988d