n層アプリケーションにアプリケーションサービス層を導入するタイミング

私は、データベースからデータをフェッチし、UIに表示し、ユーザー入力を取り込んでデータベースに書き戻すことを主な目的とするWebベースのアプリケーションを開発しています。アプリケーションは、産業用強度アルゴリズムの処理を実行することはありませんが、ピーク時に非常に多くのヒットを受け取り（後述）、1日を通して変化します。

レイヤーは、典型的なプレゼンテーション、ビジネス、データです。データ層はデータベースサーバーによって処理されます。ビジネス層には、tcp経由でデータベースサーバーにアクセスするためのDALコンポーネントが含まれます。これらの層を層に分ける必要がある選択は次のとおりです。

1. プレゼンテーション層とビジネス層は同じ層に保持できます。
2. 単独で別の層にあるプレゼンテーション層と、別の層にあるビジネス層。

選択肢2の場合、ビジネスレイヤーは、httpまたはtcpを介してWCFサービスを使用してプレゼンテーションレイヤーからアクセスされます。

ビジネスレイヤーで重い処理が行われていることはないので、上記のオプション1に傾いています。同じ理由で、新しい階層を追加してもネットワーク遅延が発生するだけだと思います。ただし、スケールアップまたはスケールアウトする必要がある場合のスケーラビリティに関しては、どちらが良い方法ですか？このアプリケーションは、1時間あたり最大600万人のユーザーをサポートできる必要があります。各ユーザーセッションには妥当な量のデータがあり、ユーザーの設定やその他の詳細が保存されます。ページレベルのキャッシュも使用します。

私はあなたの最初の評価に同意します。システムの処理にネットワークホップを追加することは、あまり意味がありません。層を物理的に分離する理由は、アプリケーション間で再利用するためです。つまり、作業の一部を実行するために同じサービスを呼び出す複数のアプリケーションがあります。おっしゃったように、ビジネスレイヤーが提供する組み込みロジックはそれほど多くありません。これまでのところ、それを使用するアプリケーションは1つだけです。

階層を論理的に分離したのは良いことですが、現時点での物理的な分離はやりすぎかもしれません。

スケーラビリティの問題に対処するための更新

BLLをプレゼンテーション層と同じ物理層に維持することが今のところ最善のアプローチであると私はまだ主張します。さらにプレゼンテーション/ bllノードを追加することでスケールアウトできます（ファットクライアントのデプロイメントを使用している場合は、Webアプリケーションで実行するのに十分簡単なため、すでに対処済みです）。また、データベースがボトルネックになっていることがわかった場合、ほとんどのデータベースは、クラスタリング/シャーディング、およびスケールアウトするためのその他の巧妙なトリックをサポートしています。これらの両方のパスを（そしてもちろん、分散キャッシングを追加して）ダウンした後でのみ、別の物理層の追加を検討します。

ただし、そこに行く前に、データアクセスレイヤーの単純なファサードよりも「心のこもった」ビジネスレイヤーの作成を検討します。最初のステップは、データマッピングを行う強力なO / RMの使用を検討することです。次に、ビジネスオブジェクトをよりインテリジェントにすることを検討してください。Domain Driven Designに書かれた一連の紙があります（この本は出発点として最適です）。ドメインモデリング、境界付きコンテキストの定義、集約ルートの検索の手順を実行すると、自然な継ぎ目を持つアーキテクチャの作成に役立ちます。これにより、アプリケーションを必要に応じて個別に拡張できる自己完結型サービスに分割できます。

物理サーバーを意味する「層」という用語を使用していると想定しています。ビジネスレイヤーとプレゼンテーションレイヤーを配布する必要がない場合は、絶対に避けます。ワイヤーを介してオブジェクトを送信すると、コストがかかり、回避できる場合は回避すべき問題が発生しやすくなります。ただし、システムが進化し、設計上の考慮事項が配布を保証するときに、より多くの層を簡単に追加できるようにアーキテクチャを設計する必要があります。通常、アプリケーションサービス層を開発しますWCFサービスと同じインターフェイスを持つクラスライブラリ/アセンブリとして。これは、プレゼンテーション層が他の外部システムとやり取りするものです。ビジネスレイヤーとプレゼンテーションレイヤーを配布する必要がない場合、プレゼンテーションレイヤーはクラスライブラリを直接参照します。それらを配布する必要がある場合、WCFサービスは、サービスにリモートでアクセスする機能を提供するサービスレイヤークラスライブラリの薄いラッパーにすぎません。

通常、将来を見据えることは良いことですが、サービスレイヤーなどを実際に導入する必要がない場合は、時間の無駄になり、システムの速度が低下する可能性があります。

システムを論理層に正しく分割することは間違いなく良いことであり、後日システムを拡張できるようになります。カップリングを減らすと、将来これを簡単に行うことができます。

たまたま、数年前にWebサイト->サービスレイヤー->それ以外のすべての大規模システムに取り組みました。

すべての上級アーキテクト/マネージャーがSOAに恋をしたため、サービスレイヤーが導入され、システムはサービス指向になる必要がありました。「他のシステムは私たちのウェブサイトのミドルティア機能を使用します」と叫びました。

この決定だけでも、プロジェクトに1年の遅れが生じました。