はじめに
この記事は、
小規模な 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やフォルダで責務を明確化しておくと、移行もスムーズ
💡 ポイント
- 最初からすべての層を作る必要はない
- 段階的に追加する方針で、保守性と理解性を両立できる