3.0 KiB
3.0 KiB
チーム開発ガイド（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 依存を解消します。