「クリーンアーキテクチャ」のインタラクターは単一責任原則に違反しますか？
SRPは、クラス（モジュール）を変更する理由は1つだけであるべきだと述べています。ボブ・マーティンのクリーンなアーキテクチャにおけるインタラクターの「義務」は、ユースケースごとに次のとおりです。コントローラーからリクエスト/入力を受信します。ドメインエンティティを調整して要求を満たします。出力データを準備します。
これは、変更する3つの理由を意味しますか？ （つまり、入力が変更されたり、ドメイン機能が拡張されたり、追加の出力フィールドが追加されたりする場合。）必要に応じて、これを解決するための適切な戦略は何ですか？ （例：CQRS？）
私の現在のアプローチは、各懸念ごとに1つずつ、3つのクラス、およびオーケストレーションとクライアントのインターフェース用の4番目のFacade/Mediatorクラスを備えたユースケースInteractorモジュールを作成することです。ただし、このPush SRP違反はモジュールレベルにまで達していませんか？
@Robert Harveyが指摘したように、「職務」という用語はだらしなく使用されていました。実際の設計の問題は、ドメインが変更された場合と、OutputDataフィールド/フォーマットが変更された場合（入力の場合はそれほどではない）の両方で必要なインタラクターの大幅な変更です。これら2つの異なる変更の理由はありませんか？
@FilipMilovanovićと@ guillaume31から気付いたように、SRPは特に違反されていません。インタラクターモジュールに3つの別々のクラスがあります。また、モジュールレベルでは、「一般的な閉鎖原則」がSRPよりも適切である可能性があります。 CCP（「コンポーネントに収集...同じ理由で同時に変更されるクラス。」）は、インタラクタークラスを分離することを提案する場合があります。 （しかし、同じユースケースに対応するクラスがロケーション間で分散されます。）回答とコメントのおかげで、これらのトレードオフがはるかに明確になりました。
ボブ・マーティンのクリーンなアーキテクチャにおけるインタラクターの「義務」は、ユースケースごとに次のとおりです。コントローラーからリクエスト/入力を受信します。ドメインエンティティを調整して要求を満たします。出力データを準備します。
これは、変更する3つの理由を意味しますか？
あなたは義務と責任を混同しています。具体的には、「責任は1つだけにする」と「1つのことだけを行う」を混同しています。
インタラクターの責任は「相互作用する」ことです。
データアクセスクラスの責任は、データにアクセスすることです。作成、読み取り、更新、削除を行うため、4つの責任はありません。 4つの義務があります
注文の少ない料理人の場合、あなたの責任は食事を作ることです。職務を別々の従業員に分割しないでください。卵を割る1人の従業員、卵を裏返す別の従業員、そして皿に置く3人目の従業員がいません。 3つすべてを実行します。
メソッドの場合、入力パラメーターの受信と出力の返送自体は責任を負いません。
データをマッピング/フォーマットして別のレイヤーに転送できるようにすることは、1つのレイヤーと見なされますが、Mapperオブジェクトに外部化できます。
また、1人、2人、または10人の共同編集者への通話を調整しても、それは単一の責任であるため、ここでは問題ありません。
変更する理由の1つは、ロバートマーティンが自分のビデオで修正したほど明確ではありません。私見、より良い説明は変更する1つの役割（c）です。これは、1つの役割だけがモジュールを変更する必要があることを意味します。たとえば、可能な役割には、DBA、製品所有者、ビジネス分析者、設計者、新しい計算ルールを持つ弁護士などがあります。つまり、cssの変更はビジネスロジックに影響を与えません。 DBシャーディングによってユースケースロジックが変更されることはありません。それで全部です。このルールはモジュールのみを対象としており、誰かがクラスやメソッドに適用できますが、このルールが作成された理由は、コードを変更できるロールによってコードを分割するためです。