Laravel アーキテクチャ

• 2023/04/01
• 読む時間 3 分間
• ishi

概要

はじめに

こんにちは、株式会社 Life Arc System の 開発担当の ishi です。

弊社ではシステム開発の際に、主に、PHP を採用しています。
案件の規模や特性に依存する部分はありますが、新規開発においては、フレームワークの Laravel を採用するケースが比較的に多い傾向にあります。

Laravel は比較的自由度の高いアーキテクチャ構成を取ることができますので、自由度が高い分、案件、プロジェクト毎に、構成が大きく変わるケースが多いかと思います。
本投稿では、弊社が良く採用する、Laravel のアーキテクチャ構成について、公開させていただきます。

弊社の Laravel アーキテクチャ構成

弊社の Laravel アーキテクチャ構成の具体例を紹介いたします。

具体的には、以下のようなディレクトリ構成にて、開発、運用しています。
原則、Laravel 標準のディレクトリ構成に沿いつつ、Services ディレクトリ(サービス層)、および、Repositories ディレクトリ(リポジトリ層)を配置しています。

  root
   ├─ app
   │   ├─ Http
   │   │   ├─ Controllers ・・・コントローラ。ルーティング先のメソッドを記述する。
   │   │   ├─ Requests ・・・フォームリクエスト。バリデーション処理を記述する。
   │   │   └─ Resources ・・・リソース。コントローラから JSON 形式で返却する際のデータ形式を記述する。
   │   ├─ Models ・・・モデル。DB と対になるモデルを記述する。
   │   ├─ Providers ・・・サービスプロバイダ。多種のクラスあり。シングルトン定義もここに記載する。
   │   ├─ Repositories ・・・リポジトリ。DB アクセス処理を記述する。
   │   └─ Services ・・・サービス。ビジネスロジックを記述する。
   ├─ database
   │    ├─ factories ・・・ファクトリ。ランダムなテスト用データを複数生成する際に使用する。
   │    ├─ migrations ・・・マイグレーション。SQL でいう CREATE 文相当を記述する。
   │    └─ seeders ・・・シーダー。テスト用データを生成する際に使用する。
   ├─ resources
   │    ├─ css ・・・CSS ファイル格納先。
   │    ├─ js ・・・JS ファイル格納先。
   │    └─ views ・・・blade ファイル格納先。
   └─ routes ・・・ルーティングを記述する。

サービス層、および、リポジトリ層の役割、および、導入理由は、以下の通りです。

1. Fat Controller の防止
   デフォルトの Laravel のディレクトリ構成に準拠すると、どうしても Fat Controller になりがちになってしまいます。
   Fat Controller 化による、保守性低下を下げるために、サービス層、リポジトリ層に分けた構成としています。
2. 各クラスの責務の明確化
   以下の通りの役割を持たせています。
   • コントローラ層 リクエスト、および、ルーティング、レスポンスに関わる処理を司る
   • サービス層 ビジネスロジックに関わる処理を司る
   • リポジトリ層 主に、DB アクセスに関わる処理を司る

コンポーネント間の呼び出し可否

上記にて、ディレクトリ構造について記載しましたが、保守性を高めるために、各クラス間の呼び出し可否についてもルールが必要です。
弊社では以下のような呼び出しルールを制定し、本ルールに則った開発をしています。

※原則 Service から Service の呼び出しは禁止としています
※他のサービスからも利用可能なサービスが必要な場合は、呼び出し可否を明確にするために、SharedService を作成する方針としています

おわりに

以上、簡単ではありますが、弊社が Laravel で開発する際のアーキテクチャ構成となります。

冒頭でお話しさせていただいた通り、Laravel は自由度の高いフレームワークですので、弊社アーキテクチャ構成がベストであるというわけではありませんが、Laravel で開発を考えている方が見えましたら、参考にしていただけると幸いです。