複数のデータベースにアクセスする必要があるアプリケーションがあります。これまでは、単一のデータベースにしかアクセスできないDALを分離していました。個別のビジネスレイヤーは、その特定のDALにのみ到達します。ビジネスレイヤの上に座っているアプリケーション（異なるWebサイト）は、データを共有する必要があった場合、任意の数のビジネスレイヤを自由に呼び出すことができました。複数のデータベースが同じDALを共有する必要がありますか？
これはしばらくの間うまくいきました。しかし、今日では、アプリケーションを構築するソリューションが大規模になっています。アプリケーション層はすべて、すべてのビジネス層に触れているようです。再利用が行われていますが、ビルドが遅れてしまい、単一のソリューションに取り込まれる不要なコードの量が不合理に見えます。
誰もこの状況に対処しましたか？ LLBLGenやNHibernateのようなORMを使ってDALにデータを共有しましたか？それとも全く別の何かを考え出したのですか？
あなたが記述したアーキテクチャは、再利用性、モジュール化、およびスケーラビリティを提供するベストプラクティスです。しかし、これらの目標を達成するバランスを失う可能性があります。見るべきことの1つは、垂直なBusiness Logic - DALスタックのサイズとサイズを持つ必要があることです。あなたのモジュールを見て、良い理由を考えてみてくださいなぜ特定のモジュールがお互いから分離されています。それらは、スケーラビリティのために顧客に別々に配備されるか、または別個に販売されるか？
垂直分離の理由がわからない場合は、いくつかのモジュールをマージして、BLとDALを共有できるより大きなモジュールにすることができます。モジュールの粒度が増加し、オーバーヘッドが減少します。
また、BLとDALの間で言及した水平の分離も見直すことができますが、通常、大規模な環境では別々の層に配置されているロジックからデータを分離することができます。また、必要なDALモジュールをすべてBLモジュールで呼び出すことも可能ですが、複数のサーバーに分割されたテーブルの場合、データベースへの複数の接続をサポートする必要があるため、Entity DBマッパーで使用するとデータベースのスケーリングが複雑になります。
私の個人的なアプローチは、あなたのBL - DALの組み合わせの粒度を見て、それらのいくつかを組み合わせることができるかどうかを見て、良いものの多くを失うことなくオーバーヘッドを減らすことです。これらのモジュールがすべてあれば、モジュール群ごとに並列化できると思います。これは、モジュール化されたアーキテクチャの資産であり、恩恵を受けることができます。何故なの？
Kroonwijkは多くの良い点を作ります。
DAL実装が（通常は）対話している物理データソースに関連付けられていることを忘れないでください。これは、BLとDALの間の対話を定義する契約とは異なります。