この 2 つは「分散パターン」に分類されています。
Remote Facade はネットワーク越しのデータアクセスのパフォーマンスを改善するためのパターンです。
複雑なデータモデルをオブジェクトで表現すると、いずれかの起点から関連オブジェクトを辿り、さらにその関連オブジェクトを辿って... といったようなプログラムを組むことになります。オンメモリのときは、オブジェクトを辿るコストはほとんどありませんが、遅いネットワーク、あるいはオーバーヘッドの大きいプロトコルを経由する場合、複雑なオブジェクト構造に直接アクセスするのは、パフォーマンス上の問題になってきます。たとえば、HTTP の REST API を設計するとき、データアクセスの粒度をレコードひとつづつとした場合、子要素が 10 あり、それぞれの子が持つ 10 の孫が必要なとき、瞬間的に必要な HTTP リクエスト数は 111 になります。
Facade パターンは、複数のオブジェクトの複雑な操作を隠蔽し、代表となる単一のオブジェクトを設けて簡単な操作を提供するというアイデアです。Remote Facade は Facade パターンが作る構造を、簡単さのためではなくパフォーマンスのために活かします。遅いリモートコールの受け口で、ありのままのオブジェクトの代わりに、アプリケーション都合に合わせて要約された形式のオブジェクトを作ります。たとえば請求書を表示するアプリケーションであれば、請求先 ID を持つ請求オブジェクトではなく、請求先企業名、請求先住所、請求明細、といった項目をすべて含む (できれば書式統一なども済ませた) オブジェクトにするのです。そうすれば、遅い通信の量を最小化できます。
Domain Model のエンティティとしては冗長だけれど、データ転送には適していると言える形に翻訳された形式のオブジェクトを、Data Transfer Object (DTO) と呼びます。コール側と送り側で同じ形式の DTO を共有しておき、インスタンスをエンコードしたものをデコードすると、同じオブジェクト復元できる、というふうに利用します。
DTO は、リモートアクセスごとに設けられ、それぞれ異なる形式になります。複数の DTO の間には、重複する部分も発生します。また、ひとつの DTO 内でも、Identity Map 上は同じインスタンスになているものが、参照箇所それぞれに展開されたりする場合もあります。DTO は、データ正規化や一意性管理に関係のあるエンティティではありません。分類で言うと Value Object になります (とはいえ、PoEAA には、だからといって DTO イコール Value Object と呼ぶ習慣には同意できない、といった批判が書かれています)。