ユースケースじゃなくてサービスとしよう
何となく使っている ユースケースという言葉ですが、自分の中でも あやふやな使い方をしているし、実際 理解もあやふや。
ある種の あやふやさ というか 曖昧さ は残ることは分かっているけれど、ユースケースという表現をつかったシステム実装を採用したいと思っている以上、全く指針の無いという訳にはいかないと思って 改めて考えてみたら、段々と「あれ？」と思うようになって 今回の結論に至ったという感じです。
以前、扱った際は*1、以下のような感じ。
と考えていました。*2
結論
システムの実装おける表現として、ユースケースは止めて、サービスにしよう。
考察／経緯
考えに至るまでの考察や経緯というかメモというか、そういうのをツラツラと。
総じて言えるのは、異なるものを同じように扱うと間違った認識につながるので使うのは止めよう、ということです。
特に自分自身が曖昧さを感じているものに対して、それっぽい理解で使ってしまうと、自分自身をミスリードしてしまうためです。
処理の集合ではない
イベントフローを処理とするならば、実装として ユースケースは処理の集合もしくはスクリプトになるだろう、というのが当初の発想でした。
でも、そもそも イベントフローは処理ではないし、シナリオはスクリプトではないので 理解が間違っています。
トランザクション境界ではない
１つのユースケースが終了すれば目的が達成され、かつ中断が行われないことを目安とする*3、とありますが、 ここでいう目的はアクターから見てシステムが達成してくれる機能を意図しており、トランザクションを意図したものではありません。
なぜ そもそも そう思ったのか、というと、中断しないこと というのを 同一トランザクションで扱うことは同値であると考えたからです。
今 思えば、SAStrutsにおいて、一連の操作（入力→確認→完了）をもってユースケースとするという整理があったりと トランザクションとは別物だと思えるヒント（経験）はあったのですが なぜだろう・・・
クリーンアーキテクチャでは使っているよ？
人は人、自分は自分。
というだけでなくて、Usecase*4という表現だと、ユースケース記述 を実装で表現しようと 自分がしてしまうから、という心理的な側面が大きいので避けよう、と。
また、そもそもクリーンアーキテクチャでいうところのUsecaseについて 自分は きちんと理解をしていないので、実装におけるUsecaseと 要件定義におけるユースケースを明確に別物として 扱えるようになっていたら別かもしれませんが、少なくとも現状では そうではないので使うのは止めておこうという感じです。
参考
混乱しがちなサービスという概念について - かとじゅんの技術日誌
ユースケース記述（ゆーすけーすきじゅつ） - ITmedia エンタープライズ
第8回 顧客の要求をユースケースに反映させる - ITmedia エンタープライズ
UseCaseの再利用性 - yoskhdia’s diary
若手エンジニア必読！超絶分かるユースケース図－全知識と書き方５ステップ
業務フロー V.S. ユースケース記述（ユースケースシナリオ） - Ken's Blog
ビジネスでも使おう！ユースケース図のキホンを解説 - Cacoo JA ブログ
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
![UMLモデリング技能認定試験〈入門レベル（L1）〉問題集改訂版 UML 2．0対応 [ 竹政昭利 ]](https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/7741/77413245.jpg?_ex=128x128 "UMLモデリング技能認定試験〈入門レベル（L1）〉問題集改訂版 UML 2．0対応 [ 竹政昭利 ]")
Use Case Examples -- Effective Samples and Tips
さいごに
ユースケースを使うのを止めて、サービスにするからといって、ユースケース的な発想を全て無くすというわけではありません。
あくまで分類するのではなくて、サービスと統一するだけです。
もし、サービスを集約したものについての分類が必要であれば、改めて考えますが、少なくとも その時にユースケースという表現は使わないようにするための戒めのメモです。
