現在、サービス ゲートウェイとして機能する nuget パッケージを作成しています。その責任は、外部サービスへの呼び出しをラップすることです。これにより、それは正しい方法で行われ、応答が正しく処理されます。その目的は、新しいクライアントが外部サービスを利用したい場合の開発時間のオーバーヘッドを削減することです。
nuget パッケージは、外部サービスのソリューションで「クライアント」と呼ばれる単一のプロジェクトから構築されます。これは、クライアント プロジェクトが共通のドメインを共有し、公開時にビルド番号を同期できるようにするためです。クライアント プロジェクトは、制御原則の反転を適用します。つまり、エントリ ポイント (外部サービスからの応答を取得するためのスタックの開始点) として機能するクラスには、多くのインターフェイス依存関係があります。
通常、IoC コンテナーとして StrucutreMap を使用しますが、依存性注入が「組み込まれている」クライアント プロジェクトをどのように構成するのか疑問に思っています。すべての消費者がパッケージの依存関係の解決を結び付けなければならないというのは間違っているようです。ただし、すべてのクライアントが StructureMap を使用し、'ClientRegistry' (初期化子) クラスを独自の起動ロジックに追加する必要があるわけではありません。
この問題を解決するための指針となる原則はありますか? または、IoC の原則に基づいて構築された複雑な nuget パッケージの良い例はありますか?