クリーンアーキテクチャの謎
クリーンアーキテクチャには、具体的なクラス構成例を示す以下の図があります。
この図の中で、Presenter と Output Boundary (Presenter のインターフェース) だけ具体実装をイメージするのが非常に難しいと思います。
「実践クリーンアーキテクチャ」というブログ記事では、Presenter について
これに敢えて触れなかった理由は MVC フレームワークとの相性が悪いからです。
と書かいた上で、MVC フレームワークとの共存方法に触れられています。
このように MVC フレームワークにおいて Presenter・Output Boundary の扱いが難しい理由を説明します。
結論
Web の MVC フレームワークで上図の通り実装できないのは、Web の MVC フレームワークが MVC 2 に基づいているのに対し、クリーンアーキテクチャの図は旧来の MVC (以後 MVC 1) に基づいているから。
Web フレームワークの場合は例えば以下のようになる。
そもそも MVC は 2 種類ある
MVC という言葉をちゃんと調べると、最初は非常に混乱します。
例えば Wikipedia の Model View Controller の頁には以下の図と説明が書いてあります。
データの変更をビューに通知するのもモデルの責任である（モデルの変更を通知するのにObserver パターンが用いられることもある）
しかし、Web 開発で馴染みのある MVC では、Model の変更を View に通知するような処理はありません。
実は、Wikipedia で書かれているような MVC は旧来の GUI 用の MVC 1 であり、Web フレームワークで使われるのは Web 用の MVC 2 なのです。
MVC 1 では、Model から View に変更を通知します。Web で実現しようとすると WebSocket などを使うことになります。
MVC 2 では、Controller が Model の変更を View に反映します。Web の MVC フレームワークにおいて、Controller の最後で View にフォワードするあれです。
MVC 1 と MVC 2 についての詳細な説明は以下の記事を参照ください。
クリーンアーキテクチャのクラス図は MVC 1
クリーンアーキテクチャのクラス構成例の図をもう一度見てみると ...
Controller から Presenter や View に依存の線が引かれていません。
これは、この図が MVC 2 ではなく MVC 1 に基づいていることを意味します。
MVC 1 を使うのであれば上図のような構成を実現可能であり、その際にアプリケーション層がプレゼンテーション層に依存しないよう、Output Boundary というインターフェースで DIP を適用することになるのです。
Web の MVC とクリーンアーキテクチャの落としどころ
一方、Web フレームワークなどの MVC 2 を使う場合、Controller は Output Data を受け取り、それを View Model に変換して View に渡すような流れになります。
その際、Output Data を View Model に変換する役割を Presenter に担わせることが考えられます。
これらをまとめると下図のようになります。
Presenter のインターフェースであった Output Boundary は DIP が不要になったため削除しています。