インターフェースの分離をファサードに適用することには意味がありますか？

Question

私のプロジェクトでは、同じフロントエンドページから異なるタイミングで呼び出されるいくつかの異なるバックエンドAPI /エンドポイントがあります。これらのエンドポイントはすべて、ページ全体の「テーマ」または「目的」にある程度関連していますが、さまざまな理由でさまざまなタイミングで呼び出され、さまざまなデータを返します。各エンドポイントから返されるデータは大きく異なります。一部のフィールドは単純なデータベースクエリを必要とし、一部は生成の処理を必要とし、一部は外部APIへの呼び出しを必要としますが、それらはすべてページのこの「テーマ」に対応し、それぞれのエンドポイント内で一時的に結合されます。

これらのエンドポイントの[〜＃〜] one [〜＃〜]の一般的なアーキテクチャはUpgradePreviewEndpointです。これは、ユーザーがアップグレードするターゲットバージョンを選択したときに呼び出されます。

他のエンドポイントはまったく同じアーキテクチャに従い、同じ抽象化を共有しているので、想像力で十分です。各エンドポイントには、リクエストオブジェクトを受け取る単一のprocessメソッドがあります。次に、エンドポイントはIResponseAssemblerに文字列応答を組み立てるように要求します。その応答の形式は質問には関係ありませんが、現在のところデフォルトではJSONです。

応答アセンブリコンポーネントの下には、アクセスするエンドポイントに関係なく、このページで使用されるすべてのビジネスロジックへの単一のゲートウェイがあります。これは私のファサードで、図ではServiceFacadeと呼ばれています。各具象IResponseAssembler実装には、対応する独自のI...Facade具象ServiceFacadeとやり取りするためのインターフェース。 ServiceFacadeは、これらのインターフェイスをすべて実装します（アセンブラごとに1つ）。

具体的なファサードは1つしかなく、非常に安定しているので、すべてのアセンブラーが直接それに依存するようにすることもできます。また、ファサード用の単一のインターフェースを作成し、すべてのアセンブラーがその1つのインターフェースに依存できるようにすることもできます。ただし、各アセンブラはファサードでいくつかのメソッドを呼び出すだけでよいため、これらのアプローチはどちらもインターフェイス分離の原則に違反します。ここで私が試みたのは、個々のインターフェイスを使用してISPを実装し、各アセンブラーが依存するServiceFacade内の不動産を切り分けることです。そうすれば、実際に必要のないものに依存することはありません。

ただし、ファサードパターンの状態については、singleインターフェースを複雑なサブシステムに提供する必要があるという多くの説明を見てきました。インターフェースの分離はその公理に違反しているようです。それどころか、具体的なServiceFacadeクラスを複数のエンティティに分割することは、この場合は本当にばかげた考えのように思えます。複数のエンドポイントを持つ唯一の理由は、サービスレイヤーではまったく関係のないGUIの一時的な結合だからです。。

このコミュニティの優秀な人々にこのデザインを精査して、私が悪質な犯罪を犯しているかどうか、またはより良いアプローチがあるかどうかを教えてください。これは、これらのAPIの設計での最初の反復ではありません。私は今feel正しい方向に進んでいるように感じますが、その感覚が私を取り込んでいるようです懐疑論を正当化するのに十分な頻度でトラブルに巻き込まれる。

casablanca · Accepted Answer

単一のインターフェースを複雑なサブシステムに提供する必要があるというファサードパターンの状態の多くの説明を見てきました。インターフェースの分離はその公理に違反しているようです。

ファサードが複雑なサブシステムへのシンプルなインターフェースを提供すると言った方が正確です。ファサードは、いくつかの低レベルの操作を新しい高レベルの抽象化に構成します。ファサードを複数のインターフェースに分離する必要があると感じる場合は、ファサードの抽象化レベルが間違っている可能性があります。

ファサードの典型的な例は、CarとEngine（低レベルの詳細）をラップし、Transmissionおよびaccelerate操作（より単純なインターフェース）を公開するbrakeです。

このエンドポイントが3つのフィールドのみを含む応答を返すとしましょう：last_upgrade_date、available_versions、expected_duration。 1つ目はデータベースクエリ、2つ目は外部APIの呼び出し、3つ目はクエリと追加処理を含むプロセスです。これらの部分の実際のビジネスロジックは、コードベースのさまざまな場所に存在します。 ServiceFacadeは、すべて1つの場所で呼び出す3つのメソッドを提供し、さまざまな場所に散在するビジネスロジックを呼び出します。

エンドポイント自体はここではファサードです。データベース/外部APIの呼び出しの詳細を隠し、3つのフィールドで構成されるよりシンプルなインターフェースを公開しています。 ServiceFacadeには追加の値はありません。実際、明確に定義された単一の責任はありません。「すべて1か所に」メソッドを追加し続けると、おそらく god object に変わります。

ServiceFacadeを削除して、関連するリポジトリ/ゲートウェイをエンドポイントに直接挿入します。これにより、SOLIDの原則に沿った、よりシンプルなアーキテクチャが得られます。