Skip to content
Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
59 lines (37 sloc) 5.96 KB
year month date title draft tags
2019
2019/02
2019-02-16
2019-02-16 UseCase とは何か
false
日報

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

UseCase がわからない...
FizzBuzz で
「3の倍数のときは fizz が返る」
「5の倍数のときは buzz が返る」
「3の倍数かつ5の倍数のときは fizzbuzz が返る」
「3の倍数でも5の倍数でもないときはそのままの数字が返る」
これは

— Yuki Anzai (@yanzm) February 15, 2019
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

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

DomainService かな https://t.co/AJ5OP4IkUv

— wada811 (@wada811) February 15, 2019
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

まぁ強いて言うならで、FizzBuzz で考えるの無理があると思う。分割するほどの責務なさそう(EnterpriseFizzBuzz くらいのものを想像してるなら別だけど…

— wada811 (@wada811) February 15, 2019
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

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

このUseCaseわからないツイートをする元になったのが https://t.co/xgNeH0vDdv このセッションで言ってた UseCase が UseCase なのかわからなくて、もしよかったらご意見聞かせてほしいです!

— Yuki Anzai (@yanzm) February 15, 2019
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

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

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

<script async class="speakerdeck-embed" data-slide="29" data-id="bd75758490674c4799d0d0a0aa99f988" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

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

これはプロダクトの文脈(FizzBuzzをどんな用途で使うか)によるかと。
その文脈上で不変性が高いならばEntityやValueObjに、低いならばUseCaseかなと。
例えば今後「4の倍数ならhuzzが返る」的な仕様追加が容易に想像できるならばUseCaseにしますねー。

— フェイ=サン@Y!の人 (@fei_kome) February 15, 2019
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

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

UseCase とは何か

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

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

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

さいごに

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

You can’t perform that action at this time.