レイヤードアーキテクチャとは？階層化設計の基本と実践

基本的な3層アーキテクチャ

最も基本的なレイヤードアーキテクチャは、3層アーキテクチャ（3-Tier Architecture）です。

3層の構成:
1. プレゼンテーション層: ユーザーインターフェースを担当
2. ビジネスロジック層: アプリケーションのビジネスルールを担当
3. データアクセス層: データベースとの通信を担当

依存関係:
- プレゼンテーション層 → ビジネスロジック層
- ビジネスロジック層 → データアクセス層
- 各層は下位の層にのみ依存し、上位の層に依存しない

メリット:
- 責任が明確に分離される
- 各層を独立して開発・テストできる
- 変更の影響範囲が限定される
- 再利用性が向上する

プレゼンテーション層（Presentation Layer）

プレゼンテーション層は、ユーザーとのインターフェースを担当する最上位のレイヤーです。

主な責任:
- ユーザーからの入力を受け取る
- 入力データの検証（フォーマットチェックなど）
- ビジネスロジック層へのリクエストの転送
- ビジネスロジック層からの結果をユーザーに表示
- エラーハンドリングとユーザーフレンドリーなエラーメッセージの表示

実装例:
- Webアプリケーション: HTML、CSS、JavaScript、React、Vue.jsなど
- モバイルアプリ: iOS、AndroidのUIコンポーネント
- デスクトップアプリ: Windows Forms、WPF、Electronなど

注意点:
- ビジネスロジックを含めない
- データベースに直接アクセスしない
- 他のレイヤーの実装詳細を知らない

ビジネスロジック層（Business Layer）

ビジネスロジック層は、アプリケーションの中核となるビジネスルールとロジックを担当します。

主な責任:
- ビジネスルールの実装（例: 注文の合計金額計算、在庫チェック）
- データの検証（ビジネスルールに基づく検証）
- トランザクション管理
- データアクセス層へのアクセス制御
- 複数のデータアクセス操作の調整

実装例:
- サービスクラス（Service Classes）
- ユースケース（Use Cases）
- ドメインモデル（Domain Models）
- アプリケーションサービス（Application Services）

注意点:
- プレゼンテーション層の実装詳細を知らない
- データベースの実装詳細を知らない（データアクセス層を通じてアクセス）
- ビジネスロジックのみを含む

データアクセス層（Data Access Layer）

データアクセス層は、データの永続化と取得を担当する最下位のレイヤーです。

主な責任:
- データベースへの接続管理
- CRUD操作（Create、Read、Update、Delete）の実装
- SQLクエリの実行
- データベースエラーの処理
- データのマッピング（データベース形式 ↔ アプリケーション形式）

実装例:
- リポジトリパターン（Repository Pattern）
- DAO（Data Access Object）
- ORM（Object-Relational Mapping）: Entity Framework、Hibernate、TypeORMなど
- データマッパー（Data Mapper）

注意点:
- ビジネスロジックを含めない
- データベースの実装詳細のみを扱う
- 他のレイヤーから独立して変更可能

依存性逆転の原則

依存性逆転の原則（Dependency Inversion Principle）は、SOLID原則の1つで、高レベルのモジュールが低レベルのモジュールに依存すべきではなく、両方が抽象に依存すべきという原則です。

従来の依存関係:

プレゼンテーション層
    ↓
ビジネスロジック層
    ↓
データアクセス層

プレゼンテーション層
    ↓
ビジネスロジック層 ← インターフェース
    ↓                    ↑
データアクセス層 ───────┘

Node.js + Expressの例

Node.jsとExpressを使用したユーザー管理システムの例です。

プロジェクト構造:

src/
├── controllers/      # プレゼンテーション層
│   └── userController.js
├── services/          # ビジネスロジック層
│   └── userService.js
├── repositories/      # データアクセス層
│   └── userRepository.js
├── models/            # データモデル
│   └── user.js
└── routes/            # ルーティング
    └── userRoutes.js

直接的な依存

直接的な依存は、レイヤーが直接他のレイヤーの実装に依存する方法です。

特徴:
- シンプルで理解しやすい
- 実装が簡単
- 結合度が高い
- テストが困難（モックが難しい）
- 変更の影響範囲が広い

例:

class UserService {
  constructor() {
    this.userRepository = new UserRepository(); // 直接インスタンス化
  }
}

依存性注入（DI）

依存性注入（Dependency Injection）は、依存関係を外部から注入する方法です。

特徴:
- 結合度が低い
- テストが容易（モックを注入可能）
- 柔軟性が高い（実装を切り替え可能）
- 実装がやや複雑

実装方法:

1. コンストラクタインジェクション:

class UserService {
     constructor(userRepository) {
       this.userRepository = userRepository; // 外部から注入
     }
   }
   
   const userRepository = new UserRepository();
   const userService = new UserService(userRepository);

class UserService {
     setUserRepository(userRepository) {
       this.userRepository = userRepository;
     }
   }

各レイヤーが持つべき責任

プレゼンテーション層:
- ✅ HTTPリクエストの受信とレスポンスの生成
- ✅ 入力データのフォーマット検証
- ✅ エラーメッセージのユーザーフレンドリーな表示
- ❌ ビジネスロジックの実装
- ❌ データベースへの直接アクセス

ビジネスロジック層:
- ✅ ビジネスルールの実装
- ✅ データのビジネス検証（例: 在庫チェック、価格計算）
- ✅ トランザクション管理
- ✅ 複数のリポジトリ操作の調整
- ❌ HTTPリクエストの直接処理
- ❌ SQLクエリの直接実行

データアクセス層:
- ✅ データベース操作の実装
- ✅ SQLクエリの実行
- ✅ データのマッピング
- ✅ データベースエラーの処理
- ❌ ビジネスロジックの実装
- ❌ データのビジネス検証

責任の境界を守る重要性:
- 各レイヤーが自分の責任のみを担当することで、変更の影響範囲が限定される
- レイヤー間の結合度が低くなり、独立してテスト・変更可能
- コードの理解が容易になり、新しいメンバーのオンボーディングが簡単

❌ 悪い例：レイヤーの責任が混在

問題のあるコード:

// Controllerでビジネスロジックとデータアクセスが混在
class UserController {
  async createUser(req, res) {
    const { email, password } = req.body;
    
    // ❌ ビジネスロジックがControllerにある
    if (password.length < 8) {
      return res.status(400).json({ error: 'Password too short' });
    }
    
    // ❌ データベースに直接アクセス
    const existingUser = await db.query('SELECT * FROM users WHERE email = ?', [email]);
    if (existingUser) {
      return res.status(400).json({ error: 'Email exists' });
    }
    
    // ❌ SQLクエリがControllerにある
    await db.query('INSERT INTO users ...', [email, password]);
    
    res.json({ success: true });
  }
}

✅ 良い例：責任が明確に分離

適切に分離されたコード:

// Controller: HTTPリクエストの処理のみ
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async createUser(req, res) {
    try {
      const userData = req.body;
      
      // ✅ フォーマット検証のみ
      if (!userData.email || !userData.password) {
        return res.status(400).json({ error: 'Email and password required' });
      }
      
      // ✅ Serviceに委譲
      const user = await this.userService.createUser(userData);
      res.status(201).json(user);
    } catch (error) {
      res.status(400).json({ error: error.message });
    }
  }
}

// Service: ビジネスロジック
class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async createUser(userData) {
    // ✅ ビジネスルールの実装
    if (userData.password.length < 8) {
      throw new Error('Password must be at least 8 characters');
    }
    
    const existingUser = await this.userRepository.findByEmail(userData.email);
    if (existingUser) {
      throw new Error('Email already exists');
    }
    
    return await this.userRepository.create(userData);
  }
}

// Repository: データアクセスのみ
class UserRepository {
  async findByEmail(email) {
    return await db.query('SELECT * FROM users WHERE email = ?', [email]);
  }

  async create(userData) {
    return await db.query('INSERT INTO users ...', [userData]);
  }
}

メリット

1. 責任の明確化:
- 各レイヤーが明確な責任を持つため、コードの理解が容易
- 新しいメンバーのオンボーディングが簡単
- コードレビューがしやすい

2. 保守性の向上:
- 変更の影響範囲が限定される
- バグの特定が容易
- リファクタリングが安全

3. テスタビリティ:
- 各レイヤーを独立してテスト可能
- モックやスタブを使った効率的なテスト
- テストの実行速度が速い

4. 再利用性:
- ビジネスロジック層を複数のプレゼンテーション層から利用可能
- データアクセス層を複数のサービスから利用可能
- コードの重複を削減

5. チーム開発:
- 異なるチームが異なるレイヤーを担当可能
- 並行開発が容易
- コンフリクトが発生しにくい

6. 技術スタックの変更:
- データベースを変更しても、ビジネスロジック層に影響しない
- UIフレームワークを変更しても、ビジネスロジック層に影響しない
- 段階的な移行が可能

デメリット

1. オーバーエンジニアリングのリスク:
- 小規模なプロジェクトでは過剰な構造化になる可能性
- シンプルなCRUDアプリケーションには不要な場合がある
- 開発の初期コストが高い

2. パフォーマンスのオーバーヘッド:
- レイヤー間の呼び出しによるオーバーヘッド
- 小さな操作でも複数のレイヤーを通過する必要がある
- 最適化が必要な場合がある

3. 学習コスト:
- チームメンバーがレイヤードアーキテクチャを理解する必要がある
- 適切な設計判断が難しい場合がある
- 経験が必要

4. 複雑性の増加:
- ファイル数が増加する
- ディレクトリ構造が複雑になる
- 小さな変更でも複数のファイルを変更する必要がある場合がある

5. アンチパターンのリスク:
- レイヤーを通過するだけの「アンチレイヤー」が発生する可能性
- 責任が不明確になる場合がある
- 適切な設計が重要

6. スケーラビリティの制限:
- 単一のアプリケーション内でのみ有効
- マイクロサービスアーキテクチャほどスケーラブルではない
- 大規模システムでは追加のパターンが必要

電子商取引システム

システムの要件:
- ユーザー管理（登録、ログイン、プロフィール管理）
- 商品管理（商品一覧、検索、詳細表示）
- 注文処理（カート、注文作成、注文履歴）
- 決済処理（支払い、請求書生成）

レイヤー構造:

┌─────────────────────────────────────┐
│  プレゼンテーション層                │
│  - UserController                   │
│  - ProductController                │
│  - OrderController                  │
│  - PaymentController                │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│  ビジネスロジック層                 │
│  - UserService                      │
│  - ProductService                   │
│  - OrderService                     │
│  - PaymentService                   │
│  - InventoryService                 │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│  データアクセス層                   │
│  - UserRepository                   │
│  - ProductRepository                │
│  - OrderRepository                  │
│  - PaymentRepository                │
│  - InventoryRepository              │
└─────────────────────────────────────┘