はじめに

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

大規模アーキテクチャや厳密な DDD を前提にせず、
「最初はシンプルに作り、破綻しそうになったら層を分ける」
という現場判断を重視しています。

C#でWebアプリケーションを開発する際、MVC構造は一般的ですが、
Entity / Model / Controller の責務が曖昧になりがちです。

本記事では、その前提のもとで
Entity / Model / MVC の役割と関心ごとを整理します。

1. 層構造の概要

私のソリューションでは以下のプロジェクト構成です：

[ Entity Project ]
  ├─ Context (Scaffolded)
  ├─ Entity (Scaffolded)
  ├─ Entity.Command
  ├─ Entity.Query
  └─ Entity.Utility
[ Web (MVC) Project ]
  ├─ wwwroot
  ├─ Model
  ├─ Model.Utility
  ├─ Controller
  ├─ View
  └─ ViewModel

Entity群

DBテーブルをスキャフォールディングで自動生成
DbContextを含む
ビジネスルールやデータの読み方・変換を拡張メソッドで付与
拡張メソッドはCommand / Query / Utility に分けて実装
DB更新や状態変更の最終責務を持つ
（ControllerやModelは「判断」までで、実際の変更はEntity側に寄せる）

※ Entityに直接メソッドを持たせないことで、
　将来の再スキャフォールディングを耐えられるようにしています

Model / Model拡張メソッド

Entityの詰め替えやアプリ依存DTOとして扱う
Entity群と同様にメソッドは Utility に分けて実装
View向けのデータ加工もここで対応する場合あり
業務ルールの判断や状態変更は行わない
Model.Utility では、Webアプリ固有の整形や変換のみを扱う

※ Controllerを肥大化させないための受け皿として使っています

MVCプロジェクト

Controller / View / ViewModel
ViewModelはページ単位で作成
簡易ページは ViewBagでデータを渡すだけの場合もあり

※ まずは作業スピードを優先し、後から分離できる余地を残します

この構成を採用している前提は以下です。

CRUD中心で業務ルールが比較的単純
画面数が少なく、Controllerがまだ肥大化していない
将来的に分離できるよう、名前空間だけは先に分けている

2. 層ごとの関心ごと

以下は、実装時に「ここに書くべきか？」と迷った際の判断基準として整理したものです。

層	主な役割	気にすること	気にしなくてよいこと
View / ViewModel	画面表示	表示形式、ユーザー入力の受け渡し	DBアクセス、業務ロジック
Controller	ユースケース層相当（小規模案件）	入力受付、View返却、簡単な業務フロー	複雑な業務ルール、Entityの内部状態管理
Model / Model拡張メソッド	アプリケーション層	Entity操作の呼び出し、DTO詰め替え	業務ルールの判断、状態変更
Entity / Entity拡張メソッド	ドメイン層	ビジネスルール、データ変換・読み方	UI表示、業務フロー全体、外部呼び出し
DbContext / DB	インフラ層	データ永続化、トランザクション	業務ロジック、UI

3. 層構造の図（現状イメージ）

View / ViewModel ← プレゼンテーション層
↓
Controller ← ユースケース層相当（小規模案件）
↓
Model / Model拡張メソッド ← アプリケーション層
↓
Entity / Entity拡張メソッド ← ドメイン層
↓
DbContext / DB ← インフラ層

Controllerに簡単な業務フローを含めても小規模案件では問題なし
Model/Entity拡張メソッドでDBアクセスや変換を整理
各層の「何を気にするか・気にしないか」を意識すると責務がぶれない

4. まとめ

小規模案件では、Controllerに業務フローが混在していても十分
Entity拡張メソッドを Command / Query / Utility に分けることで責務を整理
将来的に業務フローが複雑化した場合、
ControllerからUseCase層を切り出す方針で拡張可能
名前空間やフォルダで責務を分離しておくと、段階的な層拡張もスムーズ

💡 ポイント

各層の「関心ごと」を意識する
層構造の整理は、小規模案件でも設計理解や保守性の向上に役立つ