はじめに
ユースケース層は「ユーザーが操作する処理だけを書く場所」だと考えている人は多い。
この考えは間違いではないが、本質ではない。
ユースケース層の役割はもっと広い。
それは「アプリケーションとして必要な処理の流れ」を書く場所である。
ユーザーの直接的な操作かどうかは関係ない。
この記事ではその理由を解説する。
よくある誤解
ユースケース層 = ユーザー操作をまとめる場所
このイメージはClean Architectureを学び始めたときによく陥る誤解である。
例えば次のような操作は、誰が見てもユースケースだとわかる。
- アカウント登録
- アカウント削除
- ログイン
一方で次のような処理はどうだろうか。
- アカウント一覧取得
- アカウント詳細取得
- 検索処理
これらは「ユーザーの操作」というよりは「表示のための処理」に見えるかもしれない。
だが結論から言えば、これらも全てユースケース層に置くべき処理である。
なぜ表示用の処理もユースケース層に書くのか
理由はシンプルである。
Clean Architectureでは、ユースケース層は「アプリケーションが提供する処理の流れ」を全て受け持つ。
UI層やインフラ層から独立した「アプリ固有のルール」をここに閉じ込める。
つまり次のように考えるべきである。
ユースケース層は「ユーザーの操作」ではなく「アプリの振る舞い」を書く場所である。
「表示のための処理」も「登録・更新・削除」も区別しない。
どちらもアプリケーションとしての処理手順であり、ユースケースである。
図で整理する
[ UI層 ]
↓ ユーザー操作 or 表示要求
[ ユースケース層 ]
↓ アプリの処理手順
[ ドメイン層 ]
具体例
CreateAccountUseCase（登録処理）
Execute(ctx, input) → アカウントを作成して返す
FindAccountUseCase（表示処理）
Execute(ctx, id) → アカウントを取得して返す
これらはどちらもユースケース層に属する。
「アプリケーションの流れを表現する処理」だからである。
表示処理だからといってUI層やインフラ層に任せてしまうと、アプリケーションのルールが散逸し保守性が落ちる。
結論
ユースケース層は「ユーザーの操作」だけを書く場所ではない。
アプリケーションが提供するあらゆる処理の流れを書く場所である。
迷ったときはこう考えると良い。
その処理はアプリケーションとして必要か？
アプリが提供する一連の処理手順か？
これに「はい」と答えられるなら、ユースケース層に書く。