アーキテクチャ・構造の書き方

ディレクトリ構造とアーキテクチャの説明は、Claudeが新しいファイルを作成する際の配置先を正しく判断するために重要です。

ディレクトリ構造のテーブル記法

## ディレクトリ構造

| パス | 役割 |
|-----|------|
| \`src/app/\` | App Routerのページ・レイアウト |
| \`src/components/ui/\` | 汎用UIコンポーネント（ボタン、モーダル等） |
| \`src/components/features/\` | 機能固有コンポーネント |
| \`src/lib/\` | ユーティリティ・ヘルパー関数 |
| \`src/lib/api/\` | APIクライアント・データフェッチ |
| \`src/types/\` | 共通のTypeScript型定義 |
| \`src/hooks/\` | カスタムフック |
| \`prisma/\` | Prismaスキーマ・マイグレーション |

レイヤード・アーキテクチャの説明

## アーキテクチャ

### レイヤー構成

\`\`\`
Controller → Service → Repository → Database
\`\`\`

| レイヤー | 責務 | 配置先 |
|---------|------|--------|
| Controller | HTTPリクエスト/レスポンス処理 | \`src/controllers/\` |
| Service | ビジネスロジック | \`src/services/\` |
| Repository | データアクセス（DB操作） | \`src/repositories/\` |
| Model | ドメインモデル・型定義 | \`src/models/\` |

### ルール
- 上位レイヤーから下位レイヤーのみ依存可能（逆方向は禁止）
- Serviceは他のServiceを呼べる（ただし循環依存は禁止）
- Repositoryは必ずインターフェースを定義し、DIで注入する

依存関係のルール

### 依存関係

- \`components/ui/\` は他のディレクトリに依存しない（純粋なUI）
- \`components/features/\` は \`lib/\` と \`hooks/\` に依存してよい
- \`hooks/\` は \`lib/api/\` に依存してよい
- 循環依存は禁止。検出したら即座にリファクタリングする

ディレクトリ構造を書く際のコツは、パスと役割のペアを示すことです。パスだけでなく「何を置く場所か」を明記することで、Claudeは新しいファイルを正しい場所に配置します。