大規模なLaravelアプリケーションのサービス/アーキテクチャをどのように構造化しますか？

Question

Accepted Answer

Laravelアプリケーションが成長するにつれて、デフォルトの「太いコントローラー/太いモデル」アプローチは保守が難しくなります。大規模なアプリケーションは**追加のアーキテクチャレイヤー** — サービスクラス、アクションクラス、リポジトリ、フォームリクエスト、明確なドメイン組織 — から恩恵を受け、ビジネスロジックを整理でき、テスト可能で保守しやすくなります。

## 問題:ロジックが間違った場所に端に落ちる

```text
Small apps: logic in controllers and models is fine.
Large apps: controllers get bloated, models become "god objects", logic is duplicated
→ hard to test, maintain, and reason about. Extract logic into dedicated layers.
```

## サービスクラス — ビジネスロジックをカプセル化

```php
<?php
// move complex business logic out of controllers into a service
class OrderService {
    public function __construct(
        private PaymentGateway $payments,
        private InventoryService $inventory,
    ) {}

public function placeOrder(User $user, array $items): Order {
        // orchestrate the business process — reusable, testable, focused
        DB::transaction(function () use ($user, $items) { /* ... */ });
    }
}

// the controller stays THIN — just delegates
public function store(StoreOrderRequest $request, OrderService $orders) {
    return $orders->placeOrder($request->user(), $request->validated());
}
```

**サービスクラス**はビジネスロジックを保持し、コントローラーをシン(HTTP処理のみ)に保ち、モデルをデータに焦点を当てさせ — ロジックを再利用可能で独立してテスト可能にします。

## 大規模アプリケーション向けのその他の有用なパターン

```text
✓ Action classes — a single class per use-case (e.g. CreateUserAction) — very focused
✓ Form Requests — extract validation + authorization out of controllers
✓ API Resources — control response shape, separate from models
✓ Repository pattern — abstract data access behind interfaces (when you need it;
  often Eloquent suffices, so don't add it reflexively)
✓ Events/listeners — decouple side effects from core logic
✓ Domain-oriented organization — group code by feature/domain, not just by type
  (e.g. a modules/ structure) as the app grows
✓ Dependency injection + interfaces — for loose coupling and testability
```

## 指導原則

```text
✓ Thin controllers (HTTP only) → services/actions (business logic) → models (data)
✓ Single Responsibility — each class does one thing
✓ Depend on abstractions (interfaces) for testability and flexibility
✗ Don't over-engineer — add layers when complexity justifies them, not prematurely
```

## なぜ重要なのか

大規模なLaravelアプリケーションの構造化方法を理解することは、シニアレベルの知識です。小規模なアプリケーションで機能する慣例(コントローラーとモデルのロジック)はスケール時に崩壊し — 太いコントローラー、「神」モデル、ロジック重複、テストと保守が難しいコードにつながるからです。

追加のアーキテクチャレイヤー — 特に**サービスクラス**(ビジネスロジックをカプセル化してコントローラーをシンに保ちモデルを焦点化させ、ロジックを再利用可能でテスト可能にする)に加えて、アクションクラス、フォームリクエスト(検証/認可を抽出)、APIリソース(出力を制御)、リポジトリパターン(必要に応じてデータアクセスを抽象化)、イベント(副作用を分離)、**ドメイン指向の組織**(アプリが成長するにつれて機能でグループ化) — を知ることが、保守可能でスケーラブルなアプリケーションを構築できるようにします。

指導原則は重要です:**シンコントローラー → サービス → モデル**レイヤリング、単一責任、テスト可能性と疎結合のため抽象化(インターフェース)に依存。

同様に重要なのは**過度なエンジニアリングをしない**という判断です — 複雑性が本当に正当化される場合にレイヤーを追加するのであって、早すぎるタイミングではなく(Laravelのデフォルトはシンプルなアプリケーションで十分であり、反射的にリポジトリ/抽象化を追加すると不要な複雑性が増す)。

これらのアーキテクチャパターンと原則(および抑制)の適用を理解することは、大規模で長寿命のLaravelアプリケーションを構築し、成長するにつれて保守可能で、テスト可能で、理解しやすい状態に保つ価値があります — スケーラブルなアプリケーションを構築できる開発者を、成長するアプリケーションが絡み合い保守が難しいコードに陥る開発者から区別します。

このアーキテクチャの判断は、シニアなLaravel開発の特徴であり、深刻で成長中のアプリケーションにとって頻繁に関連する懸念です。