1. はじめに

みなさん、案件でLaravelを使用する際に、「コードのフォーマットがバラバラで、読みにくい、、」「フォーマットを統一しようとすると、PRレビューなどの手が回らない」といった経験はありませんか？

これらの課題を解決する一つの提案として、規約ベースのスケーラブルな設計思想「Portoアーキテクチャ」をご紹介します！

本記事では、Portoアーキテクチャの基本的な特徴を解説し、さらにLaravel開発の実案件で使用して感じたリアルなメリット・デメリットを共有します！

 

2. Portoアーキテクチャとは？

https://github.com/Mahmoudz/Porto

巨大なアプリケーションを、機能ごとに独立した「コンテナ」に分けて整理整頓するためのソフトウェアアーキテクチャです。

公式でも例に出されている、貨物船と照らし合わせて説明します。

まず、開発するLaravelのプロジェクト全体が、巨大な貨物船だとすると、従来の開発では、荷物や設備がごちゃごちゃと置かれており整理整頓や依存性が高くなってしまっています。

Portoアーキテクチャでは、「コンテナを使う」とルール付けしている状態です。機能や用途ごとにコンテナが用意されており、船の共用部分には各コンテナで共通して使うものしか置かれていない状態です。

こうすることで、船の中が整理整頓され、見通しの良い状態になります。

GitHubにかかれている図がわかりやすいので、ぜひご覧ください！

 

 

3. 2つの主要概念：Containers と Ship

  • Containers (コンテナ)
    • アプリケーションのビジネス機能（例：User, Product, Order）を格納する独立したモジュール。
    • 各コンテナは、自身のロジック（Actions, Tasks）、ルーティング、コントローラ、モデルなどをすべて内包する。
  • Ship (シップ)
    • アプリケーション全体の共通基盤。コアなServiceProviderやMiddleware、Exceptionなど、特定のコンテナに依存しないものを格納する場所。

 

4. リクエストの流れで理解するPortoの構造

典型的なAPIリクエストが処理される流れを追い、Portoアーキテクチャの構造を説明します。

流れとしては、主に下記の流れになりますが、特徴としてあるのが、この一連の流れが1コンテナ内で行われていることです。

  1. UI層 (API/Web Routes): リクエストの入り口
  2. Controller: リクエストを受け取り、Actionを呼び出すだけの層
  3. Action: １つのユースケース（具体的な処理）を担当する。Taskを組み合わせてビジネスロジックを実行する。
  4. Task: Actionから呼び出される、再利用可能な単一責任の小さな処理単位。
  5. Model / Repository: データベースとのやり取り。

4. 実案件で感じたメリット

  • 圧倒的な見通しの良さと保守性:
    • 「ユーザー関連の修正なら、Userコンテナだけ見ればいい」というように、影響範囲が明確になります。
    • ディレクトリ構造が規約で決まっているため、誰が書いてもコードの置き場所に迷いません。
  • 大規模チームでの並行開発のしやすさ:
    • 各開発者が担当のコンテナに集中できるため、コンフリクトが起きにくいです。
    • 新メンバーも、まずは小さなコンテナから担当することで、スムーズにプロジェクトに合流できます。
  • 自然と疎結合になり、レビューを行いやすい
    • ロジックがActionやTaskといった小さな単位に分割されているため、レビューが非常にしやすいです。
    • 依存性の注入（DI）が強制される構造なので、自然と疎結合な設計になります。

 

5. 考慮すべきデメリットと注意点

  • 学習コストの高さと規約の多さ:
    • Laravelの標準的なMVCとは全く異なるため、学習コストが高いです。
    • Porto独自の作法をチーム全員が理解する必要があります。
  • ファイル数の爆発と「お作法」感:
    • シンプルなCRUDを1つ作るだけでも、Controller, Action, Task, Request… と大量のファイルを作成する必要があります、、
    • 「これだけの処理に、こんなにファイルが必要？」という感覚は私自身もありましたし、メンバーの意見としても出てきました。
  • 小規模なプロジェクトには過剰
    • 個人開発や小規模なWebサイトに導入すると、規約の厳しさが開発スピードの足かせになる可能性が高いと思われます。

 

6. 結論：私たちのプロジェクトはPortoを採用すべきか？

  • Portoが向いているプロジェクト
    • 長期的に運用・拡張される大規模サービス
    • 開発チームの人数が多い、または増える可能性がある
    • 複雑なビジネスロジックを持つ
  • Portoが向いていないプロジェクト
    • 小規模なAPIやWebサイト
    • プロトタイピングやMVP（Minimum Viable Product）開発
    • 開発期間が非常に短い

 

7. おわりに

Portoは大規模開発において、コード規約やフォーマットを保つための強力な武器となり得ると思います！

導入を検討する際は、プロジェクトの規模や期間、チームのスキルセットを十分に考慮することが重要です！