Laravelでクリーンアーキテクチャを実現する4つのディレクトリ構成例

PHP
スポンサーリンク

Laravelの「クリーンアーキテクチャ」における構成例として、4つのディレクトリ構成を紹介します。プロジェクトの規模やチームの好みに応じて、適切なディレクトリ構成を選択してください。

構成例1：独立タイプディレクトリ構成

app/
├─ Adapters/
│   ├─ Contracts/
│   │   └─ UserRepository.php
│   └─ Eloquent/
│       └─ EloquentUserRepository.php
├─ Entities/
│   └─ User.php
├─ UseCases/
│   └─ RegisterUser.php

この構成では、アダプター、エンティティ、ユースケースをそれぞれ独立したディレクトリに配置しています。

※アダプター：アプリケーションと外部リソース（例えばデータベース）との間のインタフェースを提供する
※エンティティ：ビジネスロジックの中心的なオブジェクトを表現する
※ユースケース：アプリケーションの主要な操作を定義する

メリット

  1. アダプター、エンティティ、ユースケースがそれぞれ独立しているため、編集や変更が容易である。
  2. 構成がシンプルで理解しやすい。
  3. 各層の責任範囲が明確になる。

デメリット

  1. 関連するコードが特定のディレクトリに分散されているため、関連するコードを見つけるのが難しい。
  2. プロジェクトが大規模になると、ディレクトリが多くなり管理が複雑になる。
  3. 関連するコード間の依存関係が見えにくくなる可能性がある。

特徴

  1. クリーンアーキテクチャの原則に従って各層を独立させている。
  2. アダプター、エンティティ、ユースケースのそれぞれに専用のディレクトリがある。
  3. 一見して構造が理解しやすい。

構成例2：ドメイン駆動設計（DDD）ディレクトリ構成

app/
├─ Domain/
│   ├─ Contracts/
│   │   └─ UserRepository.php
│   ├─ Entities/
│   │   └─ User.php
│   └─ UseCases/
│       └─ RegisterUser.php
└─ Infrastructure/
    └─ Repositories/
        └─ EloquentUserRepository.php

この構成では、ドメイン駆動設計（DDD）に従って、ドメインとインフラストラクチャのディレクトリに分けています。

ドメインディレクトリには、エンティティ、ユースケース、および契約（インターフェース）が含まれ、インフラストラクチャディレクトリには具体的なリポジトリの実装が含まれます。

メリット

  1. ドメイン駆動設計に従って構造化されているため、ビジネスロジックが明確になり、保守性が向上する。
  2. ドメインとインフラストラクチャが分離されているため、技術選定の変更が容易になる。
  3. ドメインの重要性が高まり、ビジネス要件に対する理解が深まる。

デメリット

  1. ドメインとインフラストラクチャの間に依存関係があるため、依存関係の解決が必要になる。
  2. DDDに慣れていないメンバーには理解しにくい構成である可能性がある。
  3. 複雑なドメインモデルを扱う場合、設計が難しくなる。

特徴

  1. ドメイン駆動設計の原則に基づいて構成されている。
  2. ドメインとインフラストラクチャのディレクトリに分けられている。
  3. ドメイン内にエンティティ、ユースケース、および契約（インターフェース）が含まれる。

構成例3：コンポーネントベースディレクトリ構成

app/
├─ Components/
│   └─ Users/
│       ├─ Adapters/
│       │   ├─ Contracts/
│       │   │   └─ UserRepository.php
│       │   └─ Eloquent/
│       │       └─ EloquentUserRepository.php
│       ├─ Entities/
│       │   └─ User.php
│       └─ UseCases/
│           └─ RegisterUser.php

この構成では、アプリケーションの各コンポーネントごとにディレクトリを作成し、その中にアダプター、エンティティ、ユースケースを配置しています。

この方法では、関連するコードが一箇所にまとまり、特定のコンポーネントに関連するファイルを見つけやすくなります。

メリット

  1. コンポーネントごとに関連するコードが一箇所にまとまっているため、保守性が向上する。
  2. 各コンポーネントが独立しているため、コンポーネントの再利用や変更が容易である。
  3. コンポーネントごとにテストやデバッグがしやすくなる。

デメリット

  1. コンポーネント内の関連するコードが特定のファイルに分散されているため、関連するコードを見つけるのが難しい。
  2. 大規模なプロジェクトで多くのコンポーネントがある場合、ディレクトリ構造が複雑になる可能性がある。
  3. コンポーネント間の依存関係が見えにくくなる場合がある。

特徴

  1. アプリケーションの各コンポーネントごとにディレクトリを作成し、その中にアダプター、エンティティ、ユースケースを配置している。
  2. 関連するコードが一箇所にまとまり、特定のコンポーネントに関連するファイルを見つけやすくなる。
  3. コンポーネントを単位として独立させることで、モジュール性が向上する。

構成例4：ドメインオブジェクト別ディレクトリ構成

app/
├─ Domain/
│   ├─ Users/
│   │   ├─ Contracts/
│   │   │   └─ UserRepository.php
│   │   ├─ Entities/
│   │   │   └─ User.php
│   │   └─ UseCases/
│   │       └─ RegisterUser.php
└─ Infrastructure/
    ├─ Repositories/
    │   └─ Users/
    │       └─ EloquentUserRepository.php

この構成では、ドメインディレクトリ内の各ドメインオブジェクト（ユーザーなど）ごとにサブディレクトリを作成し、エンティティ、ユースケース、および契約（インターフェース）を配置しています。

また、インフラストラクチャディレクトリ内のリポジトリディレクトリでも、各ドメインオブジェクトごとにサブディレクトリを作成し、具体的なリポジトリの実装を配置しています。この方法では、ドメインオブジェクトごとに関連するコードが一箇所にまとまります。

メリット

  1. ドメインオブジェクトごとに関連するコードが一箇所にまとまっているため、保守性が向上する。
  2. 各ドメインオブジェクトに対する理解が深まり、要件定義やドキュメント作成が容易になる。
  3. ドメインオブジェクトが増えた場合でも、ディレクトリ構造が綺麗に保たれる。

デメリット

  1. ドメインオブジェクトごとにディレクトリが作成されるため、ディレクトリの深さが増して可読性が低下する。
  2. 各ドメインオブジェクト間の依存関係が見えにくくなる場合がある。
  3. ドメインオブジェクトが多くなると、ディレクトリ構造が複雑になる可能性がある。

特徴

  1. ドメインオブジェクト別ディレクトリ構成では、各ドメインオブジェクトごとにサブディレクトリが作成されている。
  2. エンティティ、ユースケース、および契約（インターフェース）が各ドメインオブジェクトのサブディレクトリ内に配置されている。
  3. インフラストラクチャディレクトリ内のリポジトリディレクトリでも、各ドメインオブジェクトごとにサブディレクトリが作成されている。

これらの構成例は、それぞれ異なる方法でクリーンアーキテクチャの原則に従ってディレクトリを分割しています。プロジェクトの要件やチームの好みに応じて、最適なディレクトリ構成を選択しましょう。

スポンサーリンク