システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る

ユースケースじゃなくてサービスとしよう

何となく使っている ユースケースという言葉ですが、自分の中でも あやふやな使い方をしているし、実際 理解もあやふや。

ある種の あやふやさ というか 曖昧さ は残ることは分かっているけれど、ユースケースという表現をつかったシステム実装を採用したいと思っている以上、全く指針の無いという訳にはいかないと思って 改めて考えてみたら、段々と「あれ?」と思うようになって 今回の結論に至ったという感じです。

以前、扱った際は*1、以下のような感じ。

  • Domainに属する情報を扱う
  • トランザクション境界
  • ユースケース記述に近しい実装
  • Actorを必ず記述する(Annotationで表現)
  • ServiceおよびDomain(Repository)により業務フローを表現する
  • コンテキストや主たる関心事の単位でフォルダ分割をして見通しを良くしても良い。
  • 単位は動詞
  • ScopeはRequestScoped

と考えていました。*2

結論

システムの実装おける表現として、ユースケースは止めて、サービスにしよう。

考察/経緯

考えに至るまでの考察や経緯というかメモというか、そういうのをツラツラと。

総じて言えるのは、異なるものを同じように扱うと間違った認識につながるので使うのは止めよう、ということです。
特に自分自身が曖昧さを感じているものに対して、それっぽい理解で使ってしまうと、自分自身をミスリードしてしまうためです。

処理の集合ではない

イベントフローを処理とするならば、実装として ユースケースは処理の集合もしくはスクリプトになるだろう、というのが当初の発想でした。

でも、そもそも イベントフローは処理ではないし、シナリオはスクリプトではないので 理解が間違っています。

トランザクション境界ではない

1つのユースケースが終了すれば目的が達成され、かつ中断が行われないことを目安とする*3、とありますが、 ここでいう目的はアクターから見てシステムが達成してくれる機能を意図しており、トランザクションを意図したものではありません。

なぜ そもそも そう思ったのか、というと、中断しないこと というのを 同一トランザクションで扱うことは同値であると考えたからです。
今 思えば、SAStrutsにおいて、一連の操作(入力→確認→完了)をもってユースケースとするという整理があったりと トランザクションとは別物だと思えるヒント(経験)はあったのですが なぜだろう・・・

クリーンアーキテクチャでは使っているよ?

人は人、自分は自分。
というだけでなくて、Usecase*4という表現だと、ユースケース記述 を実装で表現しようと 自分がしてしまうから、という心理的な側面が大きいので避けよう、と。
また、そもそもクリーンアーキテクチャでいうところのUsecaseについて 自分は きちんと理解をしていないので、実装におけるUsecaseと 要件定義におけるユースケースを明確に別物として 扱えるようになっていたら別かもしれませんが、少なくとも現状では そうではないので使うのは止めておこうという感じです。

参考

混乱しがちなサービスという概念について - かとじゅんの技術日誌

ユースケース記述の作成 – ABC Blog

ユースケース記述(ゆーすけーすきじゅつ) - ITmedia エンタープライズ

第8回 顧客の要求をユースケースに反映させる - ITmedia エンタープライズ

UseCaseの再利用性 - yoskhdia’s diary

上流工程における UML の活用

若手エンジニア必読!超絶分かるユースケース図-全知識と書き方5ステップ

業務フロー V.S. ユースケース記述(ユースケースシナリオ) - Ken's Blog

システムユースケースの概要

ビジネスでも使おう!ユースケース図のキホンを解説 - Cacoo JA ブログ

持続可能な開発を目指す ~ ドメイン・ユースケース駆動(クリーンアーキテクチャ) + 単方向に制限した処理 + FRP

Use case - Wikipedia

https://www.ibm.com/developerworks/rational/library/content/legacy/parttwo/1000/0670/0670_Schneider_Ch07.pdf

Use Case Examples -- Effective Samples and Tips

さいごに

ユースケースを使うのを止めて、サービスにするからといって、ユースケース的な発想を全て無くすというわけではありません。
あくまで分類するのではなくて、サービスと統一するだけです。
もし、サービスを集約したものについての分類が必要であれば、改めて考えますが、少なくとも その時にユースケースという表現は使わないようにするための戒めのメモです。


*1:http://vermeer.hatenablog.jp/entry/2018/03/18/172024

*2:本記事をもって、元の記事からUsecaseは削除しました

*3:UMLモデリング認定試験問題集より

*4:意図的に英語表現にしています