.dll構造を設計するためのリソース

Question

私は設計会議から出てきたばかりで、私たちが構築中のプロジェクトのいくつかの.dllを構造化する方法についてのアイデアの1つをどこから得たのかについて質問を受けました。正直なところ、この「アイデア」がどこにあるのかわかりません。そこから来たのは、私には自然な知識のように思えた。ただし、文書化された分析でこれらの意見をバックアップできれば便利です。

アセンブリ/モジュール/ソースを構築するためのさまざまなメカニズムを明示的に議論するリソースを知っている人はいますか？

更新：

アイデアは特別なものではありませんでした。一部のハードウェアの抽象化レイヤーについて説明していたので、「アプリ」はこれらのサービスを消費するのは、（独立した）プラットフォームに依存しない可能性があります。以前は、アプリが必要とするインターフェイスを宣言するinterfaces .dllと、これまでの1つのプラットフォーム用にそれらを実装する実装.dllがありました。現在、2つのプラットフォームがありますが、それらは非常によく似ています。インターフェース.dllが汚染されたり、実装が相互に参照する恐ろしいシナリオを防ぐために、一般的な抽象実装が存在できるインターフェースと特定のplatform.dllの間にある別の.dllを作成することをお勧めします。

Answer 1

機会があれば、ロバートC.マーティンの本をご覧ください：

C＃のアジャイルの原則、パターン、およびプラクティス（これは.Netを特に対象とした新しいバージョンです）

（おそらく）質問に答えるコンポーネント設計専用の章があります。

要約すると、その本を読んだ後は、これらの基準でコンポーネントを分けることを常にお勧めします：

• アセンブリはユニットまたは再利用です：一緒に使用する必要があるクラスがある場合、それらは同じアセンブリに入ります。

• アセンブリは変更の単位です：同じ理由で変更する必要のないクラスがある場合、おそらく同じアセンブリ内にあるべきではありません。

• アセンブリは展開の単位です：同じ場所に物理的に展開する必要があるクラスがある場合、おそらく同じアセンブリに配置する必要があります。

もちろん、これらは単なるヒューリスティックであり、レシピではありません。最終的には、アプリケーションのアーキテクチャ上の目標（具体的には、展開と進化/修正のアーキテクチャ上の目標）に基づいて、これら3つの設計ヒューリスティックのそれぞれの必要性を決定する必要があります。