84. ディレクトリ構成 — feature単位で切り、sharedに寄せる

フォルダは「ファイルの種類」ではなく「機能(feature)」の単位で切ります。features/products/ の中に商品機能のページ・部品・サービス・型をまとめて置けば、商品の修正で開くフォルダは1つで済みます。複数の機能から使う共通部品やパイプは shared/ に置き、依存の向きは「feature → shared」の一方向に保ちます。

この一方向ルールが実務で効くのは、影響範囲が読めるようになるからです。feature同士が直接依存し合うと、商品機能の修正が注文機能を壊す、といった連鎖が起きます。共有したいものは一度 shared に降ろしてから使う、と決めておけば、機能の追加も削除もフォルダ単位で安全に行えます。

落とし穴は、最初から完璧な構成を目指して手が止まることです。ファイルが数個のうちは平らに置いて構いません。目安は「3つ目の類似ファイルが出たら整理する」です。実際にコードが増えてから分類したほうが、想像で作った空フォルダより正確な構成になります。

サンプルコード(フレームワーク環境が必要なため表示のみ)

// ── feature単位のディレクトリ構成(例) ──
//
// src/app/
// ├── features/                  # 機能ごとにフォルダを切る
// │   ├── products/              # 商品機能のものは全部ここ
// │   │   ├── product-list-page.ts
// │   │   ├── product-card.ts
// │   │   ├── product.service.ts
// │   │   └── product.model.ts
// │   └── orders/                # 注文機能
// │       └── ...
// ├── shared/                    # 複数機能から使う共通部品
// │   ├── ui/                    # ボタン・バッジなどの表示部品
// │   └── pipes/                 # 共通パイプ
// ├── app.ts
// ├── app.config.ts
// └── app.routes.ts
//
// 依存の向きは features → shared の一方向だけ
// (features同士の直接依存と shared → features は作らない)

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗