クリーンなアーキテクチャ：各ビューには独自のプレゼンターとビューモデルが必要ですか？
私はまだクリーンアーキテクチャについて考えていて、上位レベル（ビューとプレゼンター）に関する質問に遭遇しました。ボクおじさんの写真を最初に投稿しています。
顧客のためにCRUD操作を実行できる小さなアプリケーションがあるとします。
また、顧客データをユーザーに出力する方法は3つあるとしましょう。
- 名前と生年月日を持つ新しい顧客を更新できるフォームコンポーネント。
（同じフォームが新しい顧客の作成にも使用されますが、この場合、既存のデータをロードする必要はありません）
- 顧客の名前と生年月日が画面に表示される詳細コンポーネント。
- 顧客がPDFに米国形式の誕生日で表示されるPDFエクスポート。顧客がちょうど60歳の場合、誕生日は特別な色で装飾する必要があります-これらの顧客プレゼントをもらう:)
これを実装したいとしましょう。これに対する私のアプローチは次のようになります：
出力データ（1つのファイル）用のクラスが1つだけあり、OutputDataを取得する抽象プレゼンタークラスも1つしかないことがわかります。
しかし、私には3人の具体的なプレゼンターがいて、私のビューを担当する3つの具体的なビューモデルがあります。今私の疑問：
これは正しいです？クリーンなアーキテクチャは理解できましたか？
HTMLフォームとHTML詳細の具体的なプレゼンターとビューモデルはまったく同じです。これは冗長だと感じます。これを回避し、両方のシナリオでビューモデルを再利用する必要がありますか？または、フォームの将来の要件が変わる可能性があるため、別のモデル/コンクリートのプレゼンターが必要になるため、境界線を守る必要がありますか？
私がついに日付でUS形式をもう必要としないが、言うことができれば...ヨーロッパのもの。これだけのために、新しいコンクリートのプレゼンターが必要ですか？または、プレゼンターはアプリケーションのグローバルフォーマットのユースケースを尋ねて、そのベースを決定する必要がありますか？
60歳の顧客が誕生日プレゼントを受け取る必要がある場合、このロジックは使用例に含まれている必要があります。しかし、私はこれがどこに行くのか少し迷っています...おそらく毎晩リポジトリから60のすべての顧客を取得してプレゼントを送信する別のユースケース...？しかし、これは私のビューモデルの装飾とはまったく関係ありませんか？それで、番号「60」に関する情報は私のビューモデルと私のユースケースにありますか？ 2つの冗長な時間？またはどうやって？
これは正しいです？クリーンなアーキテクチャは理解できましたか？
クリーンなアーキテクチャと整合性のあるソリューションを作成したい場合、いくつかの問題があります。
依存関係は、一方向の境界を越えるだけです。これにより、内部を外部について知る必要がなくなります。つまり、外部は変化する可能性があり、内部は気にしません。これは、オブジェクトグラフ 非循環 を維持するのにも役立ちます。コードの変更がコードを循環しないようにします。迷路を形成する傾向がある依存関係の代わりに、彼らは木を形成する傾向があります。
HTMLフォームとHTML詳細の具体的なプレゼンターとビューモデルはまったく同じです。これは冗長だと感じます。これを回避し、両方のシナリオでビューモデルを再利用する必要がありますか？または、フォームの将来の要件が変わる可能性があるため、別のモデル/コンクリートのプレゼンターが必要になるため、境界線を守る必要がありますか？
View ModelオブジェクトとOutput Dataオブジェクトは同じにしないでください。もしそうなら、Presenterは何の役にも立ちませんでした。データの表示方法を変えるのはビューの仕事ではありません。それがプレゼンターの仕事です。
私がついに日付でUS形式をもう必要としないが、言うことができれば...ヨーロッパのもの。これだけのために、新しいコンクリートのプレゼンターが必要ですか？または、プレゼンターはアプリケーションのグローバルフォーマットのユースケースを尋ねて、そのベースを決定する必要がありますか？
DatabaseとEntitiesは、日付を保存する方法について合意している必要があります。しかし、あなたのPresentersは、それらの日付を好きな形で自由に提示できるはずです。
60歳の顧客が誕生日プレゼントを受け取る必要がある場合、このロジックは使用例に含まれている必要があります。しかし、私はこれがどこに行くのか少し迷っています...おそらく毎晩リポジトリから60のすべての顧客を取得してプレゼントを送信する別のユースケース...？しかし、これは私のビューモデルの装飾とはまったく関係ありませんか？それで、番号「60」に関する情報は私のビューモデルと私のユースケースにありますか？ 2つの冗長な時間？またはどうやって？
ユーザーが日付を入力するか、今日の日付を選択し、その日付を正しいControllerに送信した場合、その日付を含むInput Dataを構築し、その日付を表す方法を使用してControllerとUse Caseは同意します。
次に、Controllerは正しいUse Case Interactorを呼び出し、Input Dataを渡します。 Use Case Interactorは、EntitiesまたはData Access（または両方）を使用して、この日付に誕生日のある人のリストを取得し、そのリストを使用してOutput Dataを作成します。 Output Dataは結果セットである必要はありません。 Use CaseとPresenterが同意する任意の構造に準拠できます。それは単にコレクションかもしれません。
Use CaseはPresenterを呼び出し、Output Dataを渡します。 Presenterが自由に姓、名、ハッピーバースデーメールの下書きを各人に送信したり、これらの人のリストが記載された1つのメールを花屋に送信したりできるようになりました。どちらを実行するかは、これを受信するように設定したプレゼンターに完全に依存します。
ビューは実際の作業を行うべきではありません。それらは興味深いロジックを縞模様にして、単にデータを投入するものにする必要があります。すでに最終形式になっているデータ。