フォルダ

Nexjs：

src/
├── app/
├── features/         # 機能ごとのディレクトリ
│   ├── auth/         # 認証機能
│   ├── posts/        # 記事投稿機能
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── actions/  # その機能に閉じたServer Actions
│   │   └── types/
│   └── dashboard/
├── shared/           # プロジェクト全体で使い回す共通基盤
│   ├── components/   # Button, Input, Modal などのUIパーツ
│   ├── hooks/        # useDebounce, useWindowSize など
│   ├── lib/          # Prisma client, Cloudflare D1, Utils
│   └── types/        # 全体で使う共通型定義

• features内の各フォルダそれぞれが小規模アプリのルートフォルダと似た構造を持つ感じになる。機能 (features)は小さく分けすぎるのではなく、最初は大きめの粒度で分けた方がいい。

• shared側がfeatures側のコンポーネントをimportするのはなるべく避ける（SidebarやHeaderのようなグローバルレイアウトは仕方がない）

ファイル

分けすぎない：

queries/
  get-posts.ts
  get-post.ts
  get-posts-by-user.ts

• 数十行のコードを役割ごとに細かく分けていたが、上記の場合 post.tsのような一つのファイルに統合した方が良い。

// post.ts
export const getPosts = ...
export const getPost = ...
export const getPostsByUser = ...

説明的すぎるコンポーネント名：

features/
  └── popular/
      └── popular-item-list-container.tsx

• 上記はpopular-list.tsxで良い。

  • フォルダ名で意図がわかる場合は以下のようにプレフィックスを省略するパターンも良い。

features/
  └── popular/
      ├── list.tsx     
      └── item.tsx    

フォルダで役割がわかる：

types/
  user.type.ts
  tag.type.ts 

validation/
  user.shcema.ts
  tag.schema.ts

• 上記のような場合、ファイル名からは役割のサフィックス（識別子）を消しても構わない。

• 同名のファイルが複数存在するのが嫌な場合は上記のような運用のままで良い。