はじめに

この記事は、
小規模な Web アプリケーション開発において、
私が実際に採用している設計の考え方を整理した連載の一部です。

大規模アーキテクチャや厳密な DDD を前提にするのではなく、

最初はできるだけシンプルに
破綻しそうになったら層を分ける
無理に抽象化しない

といった「現場での判断」を重視しています。

本記事では、設計を段階的に育てていくという方針についてまとめます。

小規模案件では、MVCのControllerに業務フローを混在させても問題はありません。
しかし、業務ロジックが複雑化してくると、責務が不明瞭になり保守性が低下します。

この記事では、段階的に層を追加して設計を整理する方針について解説します。

1. 現状の小規模案件

Controllerがユースケース層の役割を兼任
Entityの拡張メソッドでDBアクセスや変換を担当
小規模案件では十分に運用可能

図：現状イメージ

View / ViewModel ] ← プレゼンテーション層
　↓
[ Controller ] ← ユースケース層兼任
　↓
[ Model / Model拡張メソッド ] ← アプリケーション
　↓
[ Entity拡張メソッド ] ← ドメイン層
　↓
[ DbContext / Entity / DB ] ← インフラ層

2. 層を追加するタイミング

段階的に層を追加すると、以下のメリットがあります。

業務フローが複雑になったときに責務を明確化できる
Controllerが肥大化するのを防ぐ
テストしやすい構造に移行できる

追加の目安

層	追加する条件
UseCase / Service層	Controllerに業務フローが増え、複数処理をまとめる必要がある場合
Application層の拡張	DBアクセスやDTO変換が複雑になり、Model拡張メソッドだけでは対応が難しい場合

3. 段階的に追加したイメージ

[ View / ViewModel ] ← プレゼンテーション層
　↓
[ Controller ] ← 画面単位の入力受け取り・出力返却
　↓
[ UseCase / Service ] ← 業務フロー（ユースケース層）
　↓
[ Application / Model拡張メソッド ] ← DBアクセス、DTO変換
　↓
[ Entity / Entity拡張メソッド ] ← ドメイン層
　↓
[ DbContext / DB ] ← インフラ層

Controllerはあくまで画面単位の窓口に留める
UseCase層で業務フローをまとめる
Application層は手段の実装に専念

4. まとめ

小規模案件ではController兼任でもOK
業務が複雑化したら、段階的に UseCase層 → Application層 → ドメイン層 の順で整理
namespaceやフォルダで責務を明確化しておくと、移行もスムーズ

💡 ポイント

最初からすべての層を作る必要はない
段階的に追加する方針で、保守性と理解性を両立できる