🏆 プロジェクト構造最適化ガイド
🎯 目的
Nekomataプロジェクトの構造をAI開発（Claude Code等）に最適化し、効率的で保守性の高い開発環境を構築する。
📁 推奨プロジェクト構造
モノレポ構成
contents-print/
├── apps/ # フロントエンドアプリケーション
│ ├── brands/ # ブランド別アプリ
│ │ ├── neko/ # 猫ブランド
│ │ │ ├── web/ # Next.js Webアプリ
│ │ │ └── mobile/ # Expo モバイルアプリ
│ │ └── dog/ # 犬ブランド（将来）
│ └── admin/ # 管理系アプリ
│ └── dashboard/ # 管理画面
├── services/ # バックエンドサービス
│ ├── api/ # API層
│ │ ├── bff-workers/ # Backend for Frontend
│ │ └── webhooks/ # Webhook処理
│ └── integrations/ # 外部サービス連携
│ ├── shopify/ # Shopify API
│ └── firebase/ # Firebase連携
├── factory/ # 工場システム
│ └── electron-app/ # デスクトップアプリ
├── packages/ # 共通ライブラリ
│ ├── shared/ # 共通ユーティリティ
│ └── ui/ # UIコンポーネント
├── tools/ # 開発ツール
└── docs/ # ドキュメント
🔧 AI開発最適化の原則
1. 明確な役割分離
- 各ディレクトリは単一責任を持つ
- フォルダ名から機能が推測できる
- 依存関係が明確
2. 一貫した命名規則
- ケバブケース使用（例：user-profile）
- 機能を表す明確な名前
- 省略語の統一
3. 適切な抽象化
- 共通コードの packages/ への配置
- ブランド固有とブランド横断の分離
- 環境別設定の明確な管理
📊 構造の利点
開発効率の向上
- 構造の理解: 新規開発者が短時間で全体を把握
- 機能追加: 適切な場所への配置が明確
- デバッグ: 問題の発生箇所を特定しやすい
保守性の向上
- 変更の影響範囲: 局所化された変更
- テスト: 機能別の独立したテスト
- 依存関係: 明確で管理しやすい関係
スケーラビリティ
- 新ブランド追加: brands/ 下に新ディレクトリを作成
- 新機能追加: 既存構造に沿った配置
- チーム拡大: 責任範囲が明確
🛠️ 実装ガイドライン
ディレクトリ作成順序
- 基本構造: apps/, services/, packages/ の作成
- ブランド構造: brands/neko/ の設定
- 共通ライブラリ: packages/shared の整備
- 開発ツール: tools/ とスクリプトの配置
ファイル配置ルール
- 設定ファイル: 各アプリのルートに配置
- 共通設定: packages/shared/configs に配置
- 型定義: packages/shared/types に配置
- ユーティリティ: packages/shared/utils に配置
📋 移行プラン
Phase 1: 基盤整備（1週間）
- 基本ディレクトリ構造の作成
- 既存コードの分類・整理
- 共通ライブラリの抽出
Phase 2: 構造最適化（1週間）
- ブランド別構造への移行
- 共通コンポーネントの整理
- 設定ファイルの統一
Phase 3: 品質向上（1週間）
- TypeScript設定の統一
- Linting・Formatting ルールの適用
- CI/CDパイプラインの最適化
⚠️ 注意事項
避けるべき構造
- 深すぎる階層（3階層まで推奨）
- 曖昧な名前（util, misc, common等）
- 単一ファイルの巨大化
品質維持のために
- 定期的な構造レビュー
- 命名規則の徹底
- 依存関係の監視