はじめに

この記事は、小規模な 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 という階層構造で整理すると保守性が高い