@yanzm さんの以下のツイートを発端として巻き起こった話題について言及しながら UseCase とは何かについて書きたいと思います。

まず、この設問に対する僕の直接の回答は以下になります。

僕が 2 ツイートで終わらせた回答を @shinpei0213 さんは以下の記事で丁寧に言語化してくれています。

UseCase がわからない... でなんとなく感づいていましたが、このリプライで以下のセッションで混乱したことがわかりました。

スライドはアーキテクチャの理解度が低いと混乱するだけなので見ないほうがいいです。

ビジネスチームという都合の良い境界…ビジネスチームの定義次第でどうとでもなるので全く本質ではないですね。

最初の設問に登壇者の方が回答していますが、『仕様追加が容易に想像できるならばUseCaseにします』というのも本質ではないですね。
問題領域において変更が発生したならドメイン層をモデリングし直すべきです。

UseCase とは何か

アーキテクチャの静的構造の一部を切り出して単体で定義しようとしても何も理解できません。
責務分割の結果なので他の層との関係性によって定義されるものになります。
だから FizzBuzz という単なるアルゴリズムでは理解することができないんです。

UI やフレームワーク、インフラストラクチャなどの技術的関心からドメイン層を分離した場合、
アプリケーションとして動作するためにはドメイン層やインフラ層を呼び出す必要があり、
その処理を UI やフレームワークから分離した場合に、その層を Clean Architecture の文脈ではユースケース層と呼びます。
(個人的には Clean Architecture の命名が嫌いでアプリケーション層と呼んでいます。)

@shinpei0213FizzBuzzを題材にユースケース層についてを考えるのはおそらく無意味な気がする - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く の記事と同じですね。

さいごに

Clean Architecture のように構造を与えられると囚われてしまう人が多いですが、本質は構造にはありません。