クラスまたはモジュールはいつ独立したアセンブリ/ DLLに配置する必要がありますか？

クラスを独自のアセンブリ/ DLLに含めるタイミングを決定するためのガイドラインはありますか？私はしばしば二つの考え方を目にします：

1）クラスのすべての「グループ化」は、リポジトリ、サービス、DTO、インフラストラクチャなどの独自のDLLに属します。

2）すべてが単一のDLLにある必要がありますが、名前空間/フォルダーを介して分離する必要があります。たとえば、Core.Repositories、Core.Services、Core.DTOなどの追加の名前空間を持つ「Core」DLLが必要です。

仕事では、すべてを「ビジネス」と呼ばれる単一のアセンブリにまとめます。いくつかのフォルダーがありますが、本当の分離はありません。ビジネスオブジェクト（ロジックを含む、その一部はクラスであってはならない）は、「BusinessObjects」フォルダーに注意せずにまとめられます。複数のクラスで使用されるものは、「コア」フォルダーにあります。ユーティリティは「ユーティリティ」フォルダにあり、データアクセスインフラストラクチャは「データ」フォルダです。

私が取り組んでいる新しいモジュールの場合、個別のデータアクセスレイヤーが必要です（基本的なリポジトリ実装を考えてください）が、他の160（！）そこのクラス。同時に、誰もが単一のライブラリにクラスを詰め込むことに慣れているため、新しいクラスライブラリの作成について心配しています。ただし、フォルダ/ネームスペースは機能します。

各プロジェクトでカテゴリ別に分類されたクラスを持つプロジェクト（アセンブリ）を多く持つ方が、これらのクラスすべてが別々の名前空間にある場合よりも優れていると思います。プロジェクトを再利用可能にし、アプリケーション内の異なるレイヤーを表すことを目指してください。これらのプロジェクトを将来のアプリケーションで不必要に再利用でき、不必要なクラスを大量に含める必要がありません。

たとえば、あなたが述べたことに基づいて、私は間違いなく以下のプロジェクトを持っているでしょう：

• コア
• データ
• ドメイン（またはBusinessObjects）
• サービス
• ユーティリティ（またはヘルパー）

Clean Codeの「Uncle Bob」Martin、SOLID Principlesの名声は、ここで3つの原則を概説しています。

• リリースの再利用の等価性の原則：再利用のグラニュールは、リリースのグラニュールです。
• 共通クロージャの原則：一緒に変更されるクラスは一緒にパッケージ化されます。
• 一般的な再利用の原則：一緒に使用されるクラスは一緒にパッケージ化されます。

一般的な経験則では、ソリューション内のプロジェクトの数はできる限り少なくする必要があります。1つ以上の特定のユーザーストーリーを実装するために必要な場合、または単一のアセンブリが測定可能なパフォーマンスの問題を引き起こしている場合（通常、サイズが数メガバイトに達すると）のみ、それらを分割します。

私が協力している他の指導原則：

• このコードを他のプロジェクトで再利用すると思いますか？関連するWebアプリケーションの1つのグループには、すべてのアプリケーションがユーザーアカウントとログインに同じモデルを使用したため、すべてのアプリケーションが使用する1つのユーザーアカウント関連モジュールがありました。ジオメトリライブラリと数学ライブラリで同様のことを行い、DLLを含めるだけで複数のアプリケーションでそれらを再利用しました。

• プロジェクト全体を再デプロイ/再コンパイルせずに、このコードを変更/デプロイできるようにしたいですか？モジュールを再構築し、Webアプリケーションをデプロイして再起動するだけで便利な場合があります。

あなたの場合、基本的かつ一般的なリポジトリが将来再び役立つ可能性があるように思えますが、可能であれば新しいDLLに分離する価値があるかもしれません。