LaravelでAPIに特化したアーキテクチャのための柔軟なディレクトリ構成を1つ提案します。
ディレクトリ構成
app/
├─ Domain/
│ └─ {サブドメイン}/
│ ├─ Contracts/
│ ├─ Entities/
│ └─ Services/
├─ Http/
│ ├─ Controllers/
│ ├─ Middleware/
│ └─ Requests/
└─ Infrastructure/
├─ Eloquent/
│ └─ Repositories/
├─ Resources/
└─ {その他のインフラストラクチャ}/
上記のディレクトリ構成は、ドメイン駆動設計（DDD）をベースにしたアプリケーション構成で、複数のサブドメインに対応できるようになっています。
それぞれのフォルダの役割と具体例
以下では、それぞれのフォルダの役割と具体例を説明します。
Domain（ドメイン）:
このフォルダには、アプリケーションの「ビジネスロジック」や「ルール」が格納されます。
「ビジネスロジック」とは、コンピュータープログラムの中で、そのプログラムがやるべき仕事やルールを決めている部分のことです。
例えば、お店で買い物をするアプリがあったとします。 そのアプリの中で、次のようなことができるようになっている部分がビジネスロジックです。
・お店にある商品がいくつかずつあるか数える。
・割引券を使ったときに、どれだけ安くなるか計算する。
・買ったものを家まで届けるために、どれだけ送料がかかるか計算する。
・買ったものをお金で支払ったり、届けてもらったりする手続きをする。
ビジネスロジックは、プログラムがどのようなことをするか、どんなルールで動くかを決めていて、そのプログラムを使っている人たちに役立てるためにとても大事な部分です。
また、このフォルダには、サブドメインごとにフォルダが作成されています。そして、その中にContracts、Entities、Servicesが配置されます。
Contracts
ここには、インターフェースが配置されます。インターフェースは、特定の機能を実装するための契約を定義するもので、具体的な実装は含まれません。
リポジトリやサービスなど、ビジネスロジックのコンポーネントに対するインターフェースがここに置かれます。
Entities
ここには、ビジネスロジックの中心となるエンティティ（ドメインオブジェクト）が配置されます。
エンティティは、アプリケーションの主要なビジネス概念を表現し、状態とそれに関連する振る舞いを持ちます。
Services
ここには、ビジネスロジックを実行するサービスクラスが配置されます。
サービスは、複数のエンティティやリポジトリを組み合わせて、ビジネスロジックを実現する役割を担います。
このように、Domainディレクトリは、サブドメインごとにフォルダが作成されています。
また、もう少しわかりやすいように、具体例として、サブドメインが「Users」である場合を考えてみます。
- Contracts
「UserRepository」インターフェースは、ユーザー情報をデータベースから取得・保存するための契約を定義します。 - Entities
「User」エンティティは、ユーザーの名前やメールアドレスなどの状態を表現し、パスワードの検証やメールアドレスの変更などの振る舞いを持ちます。 - Services
「UserService」サービスは、User エンティティや UserRepository インターフェースを利用して、ユーザー情報の作成・更新・削除などのビジネスロジックを実行します。
Http（HTTP）:
このフォルダには、HTTPリクエストとレスポンスに関する処理が格納されます。
- Controllers（コントローラー）
クライアントからのリクエストを受け取り、適切なビジネスロジックを実行してレスポンスを返す役割を担います。 - Middleware（ミドルウェア）
リクエストとレスポンスの間に割り込み、共通処理を行う役割を担います。 - Requests（リクエスト）
クライアントからのリクエストデータのバリデーションを行います。
Infrastructure（インフラストラクチャ）:
このフォルダには、アプリケーションの技術的な詳細が格納されます。
- Eloquent（エロクエント）
Laravelで提供されるORM（オブジェクト関係マッピング）のEloquentを用いたリポジトリが格納されます。 - Resources（リソース）
APIレスポンスを整形するためのリソースクラスが格納されます。 - その他のインフラストラクチャ
他の技術的な詳細を扱うためのフォルダが用意されます。
このディレクトリ構成は、Domain、Http、Infrastructureを明確に分離し、拡張性と保守性を高めることが目的です。
また、複数のサブドメインに対応することができるため、大規模なプロジェクトにも適用しやすい構成です。
カスタマイズするなら
このディレクトリ構成では、以下の箇所をカスタマイズしてAPIに特化したアーキテクチャを構築できます。
- サブドメイン
app/Domain/{サブドメイン}ディレクトリに、アプリケーションの各サブドメインを作成します。サブドメインごとに、コントラクト、エンティティ、およびサービスを定義してください。 - コントローラー
app/Http/Controllersディレクトリに、APIのエンドポイントとなるコントローラーを作成します。各コントローラーはドメインサービスを利用してビジネスロジックを実行します。 - ミドルウェア
app/Http/Middlewareディレクトリに、アプリケーション全体に適用するミドルウェアを作成します。例えば、認証やレートリミッティングなどの機能を実装できます。 - リクエスト
app/Http/Requestsディレクトリに、リクエストバリデーションクラスを作成します。これにより、コントローラーからバリデーションロジックが分離され、可読性が向上します。 - インフラストラクチャ
app/Infrastructureディレクトリに、データ永続化やリソース変換に関するリポジトリやリソースクラスを作成します。必要に応じて、他のインフラストラクチャ要素（キャッシュ、メッセージキューなど）もここに配置できます。
このディレクトリ構成をベースに、アプリケーションの要件に合わせてカスタマイズし、APIに特化したアーキテクチャを構築することができます。
おわり
このアーキテクチャの利点は、ドメインロジック、HTTPリクエスト/レスポンス処理、およびインフラストラクチャが明確に分離されていることです。
それぞれのレイヤーは独立しており、コードの変更や拡張が容易になります。
また、リポジトリパターンやリソースクラスを使用することで、データアクセスやAPIレスポンスのフォーマットが抽象化され、再利用性が向上します。
以上、LaravelでAPIに特化したアプリケーションを開発する際の参考になれば、幸いです。
