回答:
ライブラリと実行可能ファイルのどちらを選択するかは比較的簡単です。スタンドアロンプログラムとして実行可能ファイルに入れたいコードを実行することには意味がありますか？そうでない場合は、おそらくライブラリでなければなりません。一般的に、必要なだけのライブラリよりも薄い実行可能レイヤーを使用します。これにより、バックエンドライブラリを後で再利用しやすくなり、特定のプログラムに関連付けられないためです。
ライブラリ間でコードを分割する方法を決定する限り、粒度に関する Uncle Bob Martinの記事が役立つかもしれません。
その中で、彼はOO構造について話し、コードを適切にパッケージ化するのに役立ついくつかの原則を定義しています。これらについては、彼の著書「アジャイルの原則、パターン、C＃での実践」でも詳しく説明されています。
以下の原則を要約します。
再利用のグラニュールはリリースのグラニュールです。追跡システムを通じてリリースされたコンポーネントのみを効果的に再利用できます。この顆粒がパッケージです。
ボブおじさんは、再利用を、再利用されたライブラリを自分のプログラムに静的または動的にリンクでき、ソースコードを見る必要がないと定義しています。ライブラリの新しいバージョンがリリースされたら、彼はそれを自分のシステムに統合することができます。
この方法でライブラリを処理すると、関連するものだけを同じパッケージにまとめることができます。そうしないと、ライブラリのコンシューマが理由もなく新しいバージョンにアップグレードしたり、いくつかのバージョンよりも遅れたりする可能性があります。
パッケージ内のクラスは一緒に再利用されます。パッケージ内のクラスの1つを再利用すると、それらすべてが再利用されます。
この原則は、上記の原則をサポートしています。同じパッケージ内に相互に関連のないクラスがある場合、ライブラリのユーザーに不必要なアップグレードを強いる可能性があります。
パッケージ内のクラスは、同じ種類の変更に対して閉じられる必要があります。パッケージに影響する変更は、そのパッケージ内のすべてのクラスに影響します。
この原則は、保守性について述べています。ここでの考え方は、クラスの変更方法に基づいてクラスをグループ化することです。そうすることで、変更をアプリケーションの一部にローカライズして、全体に広めることはできません。
パッケージ間の依存関係構造は、有向非巡回グラフ（DAG）である必要があります。つまり、依存関係構造に循環があってはなりません。
循環依存関係を許可しないことで、各パッケージを個別に開発し、新しい変更の準備ができたときに会社の他のメンバーに「リリース」することができます。このようにすると、2つのチームがデッドロックして、互いに作業を完了するのを待機することはありません。
長期的にコードを維持しやすくするために何ができるでしょうか？同じコンポーネント（つまり、dll、exe、コンパイル済みユニット）に無関係な関数があり、1つの関数を変更する必要がある場合、それは他の関数を壊すことになりますか？コンポーネントに変更を加える場合、そのコンポーネントのすべての機能に応じて、すべてのダウンストリームコンポーネントを再テストする必要があります。各コンポーネント内の機能を制限すると、各コンポーネントを変更するリスクが軽減されます。
また、少数の密接に関連する機能にコンポーネントを集中させることにより、1つのコンポーネントが本来の動作をすることを証明する時間がはるかに簡単になります。
答えにアプローチする簡単な方法は、「DLL」が「ダイナミックリンクライブラリ」を表し、重要な用語が「ライブラリ」であることを認識することです。
通常のライブラリに何が欲しいですか？多くの読者（ユーザー）が共有する優れた本。おそらく絶望的な瞬間に重要な質問に答えるために読者（ユーザー）によって参照されるまで、ほこりを集める便利なアイテム。リーダー（ユーザー）を他のリソースにリンクするリソース。コードライブラリも同様です。私たちは、頻繁に共有されるコード、特殊または高価値の参照モジュール、およびアーキテクチャフレームワークリソースなどをそれらの中に保持しています。ソフトウェアライブラリは、スクリプト、静的ライブラリ、動的ライブラリ、コンポーネント、リソースファイルなど、数種類のコードアーティファクトで表すことができます。
一般に、実行可能モジュールをスクリプトのように動作させることをお勧めします。システムの主要な構造とフローを明確に概説および管理しますが、重要な詳細を処理するためにライブラリからリソースを要求します。このアプローチは、混乱し、過度に専門化された、技術的な低レベルの実装の懸念で高レベルのロジックを混乱させるよりも優れています。
実行可能ファイルとライブラリの間でコードを割り当てる方法を検討するときは、論理設計と物理設計の両方を考慮する必要があります。
たとえば、オブジェクト指向システムでは、コードを論理的に整理して、適切なクラスの適切なメソッドに責任を正しく割り当てることが重要です。これは論理ソリューション設計の一部です。論理的な設計は明確で簡潔で無駄のないものである必要があり、ユーザーのドメインに関連する用語で表現する必要があります。
実際にシステムをユーザーのサイトにインストールする予定がある場合、簡単に混合および照合できる一連の簡単に展開可能なソフトウェアリソースオブジェクト（通常はファイル）にコードをバンドルする方法を指定する物理設計を作成することが懸念される場合があります。特定のターゲットシステムのニーズに。どのリソースがどの展開パッケージに属しているかを決定するには、通常、論理設計とは直接関係のない特定の物理設計の考慮事項が含まれます。たとえば、特定の展開オブジェクトのセットを受け取る顧客に応じて、特定のイメージファイル処理ライブラリを交換したい場合があります。
実際には、優れた論理設計は通常、優れた物理設計につながることがわかります。
要約すると、最も重要な原則はインテリジェントなパッケージングです。コードマテリアルを密接に関連するライブラリに編成することにより、簡単に再利用、移動、または配布できる便利なデプロイ可能なコードアーティファクトができあがります。