# チーム開発ガイド（So-Manager / Laravel12）

このドキュメントは、Laravel5 旧コードと Laravel12 新コードが混在する現状で、重複実装を避け、保守しやすい構成を保つための最小ルールを示します。

## ディレクトリと責務

- app/Models
  - 新規機能/新規テーブル向けのEloquentモデル
  - クラス名は単数・StudlyCase（例: `AdminUser`）。ファイル名＝クラス名。
  - 複雑な業務ロジックは置かない（テーブル定義・リレーション・簡易スコープのみ）。
  - 共通Traitは `app/Models/Concerns`、基底は `app/Models/BaseModel.php`。

- app/Legacy
  - 旧システム（Laravel5）の互換モデル群。テーブル名/主キー/既存メソッド・定数を維持。
  - 旧Bladeから参照されるFQCN互換のため、`LegacyServiceProvider` で `class_alias` を設定。

- app/Services
  - 画面用のユースケースを実装（複数モデルのオーケストレーション、CSV、外部API、トランザクション等）。
  - ControllerはServicesのみを呼び出し、モデルを直接組み合わせない。

- app/Support
  - 純粋な技術ユーティリティ（ビジネスロジックを含めない）。

- app/Enums
  - 共通定数はPHP列挙型で表現。旧配列定数から段階的に移行。

## 命名と重複回避

- モデルは1テーブル1モデル。`admin_user.php` のような snake_case は禁止。
- 新しい画面・機能で共通取得口が必要な場合、モデルを複製せず `app/Services/*Service.php` に集約。

## 旧→新の互換方針

- 旧Bladeは当面そのまま動かす（`\App\OperatorQue::QueClass` 等の直参照を許容）。
- 新規Bladeではモデル直参照を避け、Service経由のDTO/配列を描画。
- 段階的に旧配列定数を `app/Enums` へ置換し、`class_alias` を撤去。

### Legacy を新規で使わない（明記）

- `app/Legacy` 配下は互換専用。新規機能・新規画面・新規サービスで `Legacy` を直接参照しないこと。
- モデルは必ず `app/Models` の正式モデルを使用し、Controller からは `app/Services` 経由で利用する。

## Middleware / Provider / Controller

- Middleware: 横断的関心（認証・権限・CSRFなど）。
- Provider: 起動時の装備（DI、イベント、互換エイリアス）。
- Controller: 薄く保ち、入力検証＋Service呼び出しのみ。

## トランザクション

- 複数テーブル更新は Service 層で `DB::transaction()` を使用。

## チェックリスト（PR提出時）

- 新規モデル: テーブル/主キーを明記。既存モデルとの重複なし。
- 新規機能: 複雑な処理は Service に実装。Controllerは薄いか。
- Blade: 新規はモデル直参照なし（旧は許容）。
- ルート: 旧名互換を維持（置換時は動作確認）。

以上。段階的に Enum 化と互換撤去を進め、最終的に Legacy 依存を解消します。