3枚目と言いますか。私は、Web サービスを別のプレゼンテーション層と考える傾向があります。
次のように考えてみてください。新しいユーザーの作成 (User.Add)、特定の説明 (Products.FindByDescription) に一致するすべての製品の検索などを行うために、ビジネス レイヤー コードを呼び出す Web UI があります。
同じビジネス レイヤー コードを再利用して、サードパーティが利用できる公開 Web サービスのセットを構築できるようになりました。ユーザーを追加するメソッド (内部の User.Add() メソッドを呼び出すメソッド、製品を検索する別のメソッドなど) が存在する可能性があります。
得られるのは、同じ基礎となるデータおよびビジネス ロジックに対するプレゼンテーション/インターフェイスの並列セットです。
舞台裏 (Web サービスや UI レイヤーの範囲外) では、ビジネス レイヤーがデータ アクセス レイヤーを呼び出し、データベースへの物理的なクエリを処理します。別の DBMS に変更する場合、理想的には (そして理論的には)、新しいデータベースのデータ層を再構築し、すべてが簡単に機能するようにする必要があります。
ビジネス層には、ユーザー名の長さを 4 ~ 15 文字にする必要があるなどのルールが含まれています。ユーザーは、アクセスできるストアにある製品のみを検索してロードすることができます。等
ビジネス ルールを変更することにした場合 (たとえば、ユーザーは任意のストアの商品をその状態で検索できるようにするなど)、変更を 1 か所で行うだけで、Web サービスや UI を操作して機能させる必要はありません。