はじめに
Day03では、Node.jsで最小のAPIを作り、
「APIはJSONを返すだけ」という役割を確認した。
今回はそこから一歩進んで、
APIをどう分けて考えるか
つまり Controller的な考え方 を整理する。
この回は、
コード量よりも 構造の理解 を重視する。
なぜ分割が必要になるのか
最初は、1ファイルに全部書いても動く。
ただし少し処理が増えると、すぐにこうなる。
- 何をしているAPIなのか分からない
- 修正すると別の処理が壊れそう
- 似たような処理が増えてくる
これは 処理の役割が混ざっている 状態。
Webアプリでは、
役割ごとに考えること がとても重要になる。
APIの中で起きていること
APIの中では、実は次のような処理が連続している。
- リクエストを受け取る
- 入力内容を確認する
- 処理を実行する
- 結果を返す
これらを全部一緒に書くと、
「何をしているAPIか」が見えなくなる。
Controller的な役割とは
ここで出てくるのが Controller的な考え方。
Controllerの役割は、とても限定的。
- リクエストを受け取る
- 必要な処理を呼び出す
- 結果を返す
自分では判断しない。処理しない。
あくまで「交通整理役」。
処理はどこに書くのか
実際の処理は、別の役割に任せる。
たとえば、
- データを加工する
- 業務ルールを適用する
- 将来DBとやり取りする
こういったものは、
Service的な役割 に切り出す。
分割後のイメージ
routes / controller
└─ リクエスト受付
service
└─ 実際の処理
Controllerは薄く、
Serviceが少し厚くなる。
この構造は、
- Expressでも
- NestJSでも
- 将来の別言語でも
ほぼ共通。
TypeScriptがここで効いてくる
役割を分けると、
データの受け渡し が増える。
ここでTypeScriptの型が効いてくる。
- Controller → Service
- Service → Controller
この間で、
「どんなデータが来て、何を返すのか」
を型で明示できる。
これは、
コードで会話する感覚に近い。
なぜ NestJS に近づいているのか
ここまでの考え方は、
実は NestJSの基本構造そのもの。
- Controller
- Service
- Module
Expressでこの分割を理解しておくと、
NestJSに移行したときに
「なぜこうなっているのか」がすぐ分かる。
今は「完璧な設計」を目指さない
この段階で、
- 正解の分割
- 美しい設計
- 将来を見越した構成
を目指す必要はない。
大事なのは、
- 役割を分けて考える
- 混ぜない意識を持つ
それだけ。
Day04 のまとめ
- APIは複数の役割でできている
- Controllerは「受け取って返す」だけ
- 処理はServiceに寄せる
- TypeScriptは役割間の橋渡しになる
- この考え方はNestJSに直結する
次回は、
この分割を実コードで形にする。
次回予告
Day05：APIを分割して書いてみる（Controller / Service 実装）
コメント