UseCase層ってなんだろう？

Controllerがあるし、Serviceもあるし、
Eloquentでデータも取れる。
じゃあ「UseCase」って何をやるんだ？って。

調べても、説明がふわっとしていて、
「アプリケーションのビジネスロジックを担う層です」
みたいな定義はあるんだけど、
実際にコードを書くと「で、どこに書くんだ？」ってなる。

でもいろいろ試していくうちに、
「UseCaseは“橋渡し”なんだな」って思うようになりました。

Controllerがやること、Repositoryがやること

まず整理してみると、
Controllerはリクエストの入口。
RepositoryはDBへの出口。

で、その間に「アプリのやりたいこと」をまとめる層がほしくなる。
それがUseCase。

Controller → UseCase → Repository

Controllerは“どう受け取るか”を考えて、
Repositoryは“どう取ってくるか”を考える。
その間で、「何を実現したいか」をコードで表現するのがUseCase。

たとえばこんな感じ

final class PublishUseCase
{
    public function __construct(
        private PublishPageBatchApplicationService $batchService,
        private PublishBookJobFactory $jobFactory,
    ) {}

    public function handle(PublishCommand $command): void
    {
        $jobs = $this->batchService->createBatchJobs(
            $command->spotRows,
            $command->pageRange,
            $command->capacity,
            $command->dictionaries
        );

        foreach ($jobs as $job) {
            $this->jobFactory->dispatch($job);
        }
    }
}

最初に見たとき、「これただの処理まとめじゃん」と思いました。
でも、これが “UseCaseらしさ” なんですよね。

RepositoryみたいにDBの中身は知らないし、
ControllerみたいにHTTPも知らない。
でもアプリの「やりたいことの順番」はここで決める。

つまり、アプリの意図をコードで語る場所。

UseCaseは「何をするか」を決める層

だんだん分かってきたのは、
UseCaseは「順番と責務の整理」をする層だということ。

1. Controllerから入力を受け取る（Command／Input）
2. ドメインやRepositoryを呼び出す（必要な順序で）
3. 結果を整形して返す（DTOやViewModelなど）

UseCase自体は重いロジックを持たず、
むしろ複数の処理を並べてつなぐ“司令塔”の役割。

「これをやったあとに、これをやって、最後にこれを保存する」
そういう“物語の進行役”みたいな感じです。

いちばん助かったのは「流れを変えやすい」こと

以前はControllerに
Repository呼び出し＋バリデーション＋整形＋メール送信…
みたいな処理が全部入っていました。

でもこれをUseCaseに移したら、
Controllerは「依頼するだけ」になって、
フローを変えたいときにすぐ動かせるようになりました。

// Controller側
$command = new PublishCommand($request->validated());
$useCase->handle($command);

Controllerがすっきりして、
「アプリの進行」はUseCaseに閉じる。
その結果、どこで何をやってるかが整理された感じがあります。

使ってみて感じたこと

UseCaseを入れると、コード量は確かに増えます。
でも「意味のある行が増える」感じがします。

• どんな操作があるかが一覧で見える
• 「このアプリは何をできるのか」がクラス単位で整理される
• ControllerやRepositoryの責務が自然に軽くなる

いわば、「アプリの文章構造」が見えるようになるのがでかいですね。

Controller … 依頼する人
UseCase … 物語を進める人
ApplicationService … 手を動かす人
Repository … データを持ってくる人

UseCaseがいるだけで、
このチーム構造が整理される感じがあります。

まとめ：UseCaseは“整理するための層”

Repositoryって本当に必要？

最初は「そんな層いる？」と思っていたけど、
結果的にいちばん見通しをよくしてくれたのがここでした。

UseCaseはビジネスロジックを詰め込む場所ではなく、
アプリ全体の流れを整えるための“整理棚”みたいなもの。

ControllerとRepositoryのあいだで、
やるべきことの順序を丁寧に書いておく。
それだけで、Laravelのコードが一気に読みやすくなりました。

今回は以上です！