フォルダ

Nexjs：

src/
├── app/              # Next.js App Router (Routing, Layout, Page)
├── 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側から渡されたpropsやchildrenに応じて描画のみを担うようにする。この逆転現象、つまり shared側がfeatures側のコンポーネントをimportするのはなるべく避ける（SidebarやHeaderのようなグローバルレイアウトは仕方がない）

ファイル

分けすぎない：

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

• 数十行のコードを役割ごとに細かくファイルに分けていたが、上記の場合 post.tsや get-post.ts１ファイルにロジックを統合した方が良い。

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

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

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

• 上記はpopular-list.tsxで良い。他の例としてload-more-button.tsxというコンポーネントがあるなら、load-more.tsxだけで振る舞いが伝わるので充分。

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

• フォルダ名で意図がわかる場合は上記でも良い。同じファイル名が複数できる可能性が高いので接頭辞だけ付けるパターン（popular-list.tsx）が一番良いと感じる。

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

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

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

• 上記のような場合、ファイル名からは役割を消して良い。