クラスまたはモジュールを別のアセンブリ/ DLLに含める必要があるのはいつですか？
クラスを独自のアセンブリ/ DLLに含めるタイミングを決定するためのガイドラインはありますか？私はしばしば2つの考え方の学校を目にします。
1）クラスのすべての「グループ化」は独自のDLLに属します。例：リポジトリ、サービス、DTO、インフラストラクチャなど）.
2）すべてが1つのDLLに含まれている必要がありますが、名前空間/フォルダを介して分離されています。たとえば、 "Core"がありますDLL追加の名前空間、たとえばCore.Repositories、Core .Services、Core.DTOなど.
職場では、「ビジネス」と呼ばれる単一のアセンブリにすべてをまとめます。いくつかのフォルダーはありますが、実際の分離はありません-ビジネスオブジェクト（ロジックを含む、クラスであってはならないものもある）は、注意せずに "BusinessObjects"フォルダーにまとめられます。複数のクラスで使用されるものは「Core」フォルダにあります。ユーティリティは「Utilities」フォルダーにあり、データアクセスインフラストラクチャは「Data」フォルダーにあります。
私が取り組んでいる新しいモジュールの場合、個別のデータアクセスレイヤーが必要です（基本的なリポジトリの実装を考えてください）が、他の160と一緒に "BusinessObjects"フォルダーの下に単に投げたくありません（！）クラスがあります。同時に、誰もが単一のライブラリにクラスを詰め込むことに慣れているので、新しいクラスライブラリの作成について心配しています。ただし、フォルダー/名前空間は機能します。
カテゴリごとにクラスで分割されたクラスを持つプロジェクト（つまりアセンブリ）を、これらのクラスすべてを別々の名前空間に持つ1つのプロジェクトよりも多くする方がよいと思います。プロジェクトが再利用可能で、アプリケーションのさまざまなレイヤーを表すことを目指してください。その後、不必要なクラスの束全体を含める必要なく、これらのプロジェクトを将来のアプリケーションで適切に再利用できます。
たとえば、あなたが言ったことに基づいて、私は間違いなく次のプロジェクトを持っています：
- 芯
- データ
- ドメイン（またはBusinessObjects）
- サービス
- ユーティリティ（またはヘルパー）
"Uncle Bob" Martin of Clean Code、SOLID原則の名声は概説しています ここに3つの原則 ：
- リリース再利用の等価原理：再利用のグラニュールは、リリースのグラニュールです。
- Common Closure Principle：一緒に変化するクラスは一緒にパッケージ化されます。
- 一般的な再利用の原則：一緒に使用されるクラスは一緒にパッケージ化されます。
一般的な経験則では、ソリューション内のプロジェクトの数はできるだけ少なくする必要があります。 1つ以上の特定のユーザーストーリーを実装するために必要な場合、または単一のアセンブリが測定可能なパフォーマンスの問題を引き起こしている場合（通常、最大で数メガバイトになると）、それらを分割します。
私が一緒に働くいくつかの他の指導原則：
このコードを他のプロジェクトで再利用すると思いますか？関連するWebアプリケーションの1つのグループでは、すべてのアプリケーションがユーザーアカウントとログインに同じモデルを使用していたため、すべてのアプリケーションが使用する1つのユーザーアカウント関連モジュールがありました。 DLLを含めるだけで、ジオメトリライブラリと数学ライブラリで同様のことを行い、それらを複数のアプリケーションで再利用しました。
プロジェクト全体を再デプロイ/再コンパイルせずに、このコードを変更/デプロイできるようにしますか？場合によっては、モジュールを再構築し、Webアプリケーションをデプロイして再起動するだけでも便利です。
あなたの場合、基本的で一般的なリポジトリは将来再び役立つかもしれませんが、可能であればそれを新しいDLLに分離することは価値があるかもしれません。