実践クリーンアーキテクチャ 音ズレ修正Ver.【プログラミング】

ライブ放送のマイクが音ズレしていたので対処しました。
元動画: • 実践クリーンアーキテクチャ【プログラミング】
JJUC CCC 2019 Spring の講演「「先行開発！クリーンアーキテクチャ -- ゼロから始める新規開発」の再演です。
講演の概要は下記URLのイベントページをご覧ください。
URL
イベントページ: nrs-seminar.co...
Togetter: togetter.com/l...
文字起こし（ログミーTechさま）: logmi.jp/tech/...
スライド: speakerdeck.co...
github: github.com/nrs...
解説記事: nrslib.com/cle...
cf.
C#: github.com/nrs...
チャンネル登録
/ @nrslib
Twitter
/ nrslib
補足
iOS Clean Architecture が Rovert C. Maritin 氏の発表と口走ってますが、発表者の勘違いです。

[@tatsunokokendu]

めっちゃわかりやすい。天才

[@dancerecorddevelop4740]

わかりやすすぎた玄白！

[@Xmfchmgmdkvxgmx]

これはわかりやすい

[@てんかわ-c1m]

outputdataとviewmodelの違いがよくわからないです。
outputdataをそのままviewに渡してはダメなのでしょうか？

[@nrslib]

基本的にダメってことはないです！
外から内向きの依存（View -> OutputData）は問題となることはそう多くないです。
その上で問題を挙げるとすれば、View の都合が Interactor に侵食することです。
本来であれば View のためのパラメータはビジネスロジック（Interactor）から隔絶されるべきです。
しかし、OutputData にパラメータが記述されると、そのパラメータをセットするのが Interactor の役目になります。
これが問題を起こすのは UI が複数になるときです。’
大多数のソフトウェアでは UI は単一ですが、長期的に運用されると老朽化を理由に UI を挿げ替えるようなことが発生します。
これは時間軸がズレているだけで UI が複数存在することを意味します。
しかも、よく成功した、大切なソフトウェアであればあるほどに起こりがちなことです。
さて、このとき、Interactor に旧 UI のためのパラメータを導出するロジックが記述されていると……？
これはクリーンアーキテクチャの考えではありませんが、ライフサイクルの異なるもの同士（今回であれば UI とビジネスロジック）の依存はなるべくなら切っておくに越したことがありません。
そのため、ViewModel を作って、View のためのパラメータを OutputData から導出するのは Presenter の役目にする方が無難といった結論になります。

[@iimurakazuo]

@@nrslib 　以下の部分を特に参考にさせていただきます。
「これは時間軸がズレているだけで UI が複数存在することを意味します。」