クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High

何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている

[IzumiSy]

書いた。

[honma200]

依存の問題でしょ？この本に口を酸っぱくして書いてるじゃん。この本の失敗はこの4重丸と右下の図にクリーンアーキテクチャって書いたこと。本質は何が、何に依存することで品質や変更に強くすることでしょ？

[turanukimaru]

不要なら必要になるまで作らなくていいのではってのはいつも思う。ただ出力形式は使い方＝ユースケースによるのと、コントローラはどうしても環境／FWに依存してしまうので別環境対応するときは分けときゃ良かったと

[Phenomenon]

PresenterがControllerに依存しちゃうからじゃないの？ PresenterとControllerはUsecaseだけに依存させたいじゃん。Controller変更したらPresenterも変更することにならない？

[griefworker]

「UsecaseがPresenterを呼び出すメリットは"UsecaseがPresenterをどう使うかを制御できること"」

[nomore1013]

webフレームワークだと素直に値返したほうがいいのよく分かる

[esodov]

非同期な処理以外だと考えなくていいと思う

[jsstudy]

UsecaseがPresenterを呼び出すメリットは"UsecaseがPresenterをどう使うかを制御できること" 結論としてメリットはこれに尽きる。

[tinsep19]

画面に結果に依存しないオブジェクトが必要な場合や、結果不要になるオブジェクトをフィルターしたりするのに必要だからかな？

[w1234567]

Usecaseクラスなんだから戻り値をどう扱うのかもUsecaseクラスにドメイン知識として書きたいんだよ。APIサーバーの件は、Usecaseクラスの呼び出しをラップして共通のPresenterからレスポンスに変換する部品を書けば綺麗だと思う

[bambookun]

相性の話ももちろんあって、例えばネイティブアプリの場合はアプリケーション部分をどう作っているか（MVVM or MVP or..）にもよって変わってくるよな。 結論、依存の方向が間違っていなければ問題無いと思う。

[nakag0711]

ロボットアームを移動してそれが成功したという結果を返すUの「出力」は何か？OPという仕組みはアームの駆動コマンドという出力には向いているが、成功しましたと表示するのには向いていないように見える

[nunulk]

"とはいえ「ボブおじさんが言ってるんだからそうするのが当たり前」という考え方はあまりにも思考停止すぎる。"