はじめに
この記事は、小規模な Web アプリケーション開発において、
私が実際に採用している設計の考え方を整理した連載の一部です。
大規模アーキテクチャや厳密な DDD を前提にせず、
「最初はシンプルに作り、必要になったら層を分ける」
という現場判断を重視しています。
Webアプリケーション開発では、
「ユースケース層（UseCase層）」と
「アプリケーション層（Application層）」
という言葉をよく目にしますが、両者の違いは曖昧になりがちです。
本記事では、「何をするか」と「どう実現するか」
という視点から、両者の責務の違いと
MVC設計との関係を整理します。
本記事の前提
本記事では、DBスキーマ変更に伴う
スキャフォールディングを繰り返す前提を置いています。
そのため、リポジトリパターンによる抽象化は省略し、
Application層で直接 DbContext を扱う設計としています。
1. ユースケース層とは
主な役割
- ユーザー視点・業務視点で「何をするか」を表現する層
- 複数処理の順序や分岐、条件分岐などの業務フローを管理
- トランザクション単位の処理制御を行うことが多い
呼び出す対象
- アプリケーション層（Model/Service）
- ドメイン層（Entity / ValueObject）
実装例
public class OrderUseCase
{
private readonly DbContext _dbContext;
public OrderUseCase(DbContext dbContext)
{
_dbContext = dbContext;
}
public void RegisterOrder(OrderDto request)
{
// 業務フロー（何をするか）
request.Validate();
// 実現手段はアプリケーション層に委譲
var entity = request.ToEntity();
_dbContext.AddOrder(entity);
}
}
小規模案件では Controller がこの UseCase を直接呼び出します。
業務フローが単純な場合は、UseCaseを省略し
Controller に直接記述することもあります。
複雑化した場合に切り出せるよう、責務だけを意識しています。
2. アプリケーション層とは
主な役割
- ユースケース層の要求を実現する手段を実装する層
- DBアクセス、DTO変換、外部API呼び出しなどを担当
- 「どうやって実現するか」にフォーカス
呼び出す対象
- ドメイン層（Entity / ValueObject）
- インフラ層（DbContext / 外部サービス）
実装例
public static class OrderExtensions
{
public static Order ToEntity(this OrderDto dto)
{
return new Order
{
Id = dto.Id,
Amount = dto.Amount,
CreatedAt = DateTime.Now
};
}
public static void AddOrder(this DbContext me, Order order)
{
me.Orders.Add(order);
me.SaveChanges();
}
}
- DBアクセスやDTO詰め替えなど、手段の実装に集中している
3. 層の違いまとめ
| 項目 | ユースケース層 | アプリケーション層 |
|---|---|---|
| 視点 | ユーザー / 業務 | システム内部 / 手段 |
| 主な役割 | 「何をするか」を表現（業務フロー） | 「どう実現するか」を実装（DB・DTO・API呼び出し） |
| 呼び出す対象 | アプリケーション層 / ドメイン層 | ドメイン層 / インフラ層 |
| トランザクション | 業務フロー単位で管理 | 個別処理単位で扱うことが多い |
| 例 | 注文登録の手順: バリデーション → 支払い → 在庫更新 | DBリポジトリ呼び出し → Entity詰め替え → API呼び出し |
💡 覚え方
- ユースケース層 = 「何をしたいか」
- アプリケーション層 = 「それをどう実現するか」
4. MVCとの関係
- 小規模案件では、
Controllerがユースケース層の役割を兼任することも多い - 複雑化した場合は、Controllerから業務フローを抜き出して
UseCaseクラス にまとめると責務が明確化される - アプリケーション層（Model / Service / 拡張メソッドなど）は、
DBやDTO変換など「手段」に集中させる
5. まとめ
- ユースケース層とアプリケーション層の違いを理解することで、
責務の分離がしやすくなる - 小規模案件では兼任でもOK
- 中規模以上では、Controller → UseCase → Application → Domain → Infrastructure という階層構造で整理すると保守性が高い