13種類の部品の役割分担
NestJSアプリを構成する3種類の部品の役割をコメントで整理した例です。どんなに大きなアプリでも、この3つの役割分担の繰り返しでできているという全体像を示します。
// NestJS の3部品は「受付」「実務担当」「部署」に例えられる
//
// コントローラ = 受付
// 「GET /users が来たらこの処理」という対応表を持つ
// 自分では仕事をせず、実務担当に依頼して結果を返す
//
// プロバイダ(サービス) = 実務担当
// 「ユーザー一覧を取得する」などの業務処理そのもの
// HTTP のことは知らず、どこから呼ばれても同じ仕事をする
//
// モジュール = 部署
// 受付と実務担当を機能ごとにまとめる入れ物
// 「ユーザー部署」「注文部署」のように機能単位で増えていく
21つのリクエストが流れる道筋
GET /users というリクエストが部品の間をどう流れるかを示した例です。コントローラが受けてサービスに任せ、結果が逆順に戻るという流れは、この後のすべてのレッスンの土台になります。
// GET /users が来たときの流れ
//
// クライアント
// │ ① GET /users
// ▼
// UsersController ── ② findAll() を呼ぶ ──▶ UsersService
// ▲ │
// └──── ③ ユーザー一覧を返す ◀─────────────┘
// │ ④ JSON レスポンス
// ▼
// クライアント
//
// コントローラは「受けて、任せて、返す」だけに徹する
3素のExpressとの構成の違い
同じAPIを素のExpressで書いた場合との対比です。Expressは自由に書ける反面すべてが1ファイルに混ざりやすく、NestJSは置き場所が決まっているという構成面の違いを示します。
// 素の Express: ルーティングもロジックも1か所に書ける(=混ざりやすい)
// const app = express();
// app.get("/users", (req, res) => {
// // ルーティング・業務処理・レスポンス整形が全部ここに…
// res.json([{ id: 1, name: "Alice" }]);
// });
//
// NestJS: 役割ごとにファイルが分かれる(=置き場所が決まっている)
// users.controller.ts … URL との対応だけ
// users.service.ts … 業務処理だけ
// users.module.ts … 2つを束ねる宣言だけ
//
// 書く量は増えるが、人数が増えても構成が崩れないのが NestJS の狙い
4機能ごとのディレクトリ構成
実務のNestJSプロジェクトで標準的な「機能ごとにフォルダを切る」構成です。users・orders のように機能単位でひとまとまりになるため、担当機能のコードを探す場所が一目で分かります。
// 機能(リソース)ごとにフォルダを切るのが NestJS の標準スタイル
// src/
// main.ts ← 起動処理
// app.module.ts ← ルートモジュール
// users/ ← ユーザー機能はこの中で完結
// users.module.ts
// users.controller.ts
// users.service.ts
// orders/ ← 注文機能も同じ形の繰り返し
// orders.module.ts
// orders.controller.ts
// orders.service.ts
// 「新機能 = フォルダを1つ増やす」という増築のしかたになる
5実務プロジェクトの全体構成
認証やDB接続を含む実務規模のプロジェクト構成例です。機能フォルダの繰り返しに加えて、横断的な部品を common/ にまとめるのが定番で、中規模以上のチーム開発でよく見る形です。
// 実務規模のプロジェクト構成の例
// src/
// main.ts
// app.module.ts
// auth/ ← 認証機能(ログイン・トークン発行)
// users/ ← ユーザー管理
// orders/ ← 注文管理
// common/ ← 機能をまたぐ共通部品の置き場
// pipes/ ← 入力変換(後のレッスンで学ぶ)
// guards/ ← アクセス制御(後のレッスンで学ぶ)
// filters/ ← エラー整形(後のレッスンで学ぶ)
//
// どの会社のプロジェクトでもほぼこの形なので、
// 一度覚えれば初めてのコードベースでも迷わず読み始められる