標準的な API 主導の接続モデルでは、第 1 層 (エクスペリエンス API) が特定のエンゲージメント システムに合わせてデータをカスタマイズする役割を担います。
Experience APIは、下位層からコアデータを取得し、各コンシューマーに必要な特定の戻り形式（例：モバイル用JSON、レガシーWeb用XML）とセキュリティプロトコル（例：Salesforce用OAuth、Web用APIキー）に変換します。オプションBは、これらの変換とセキュリティ適用がこの外側のレイヤーで行われるべきであることを正しく認識しています。APIゲートウェイ（オプションA）は一般的なセキュリティとレート制限を提供できますが、エンゲージメントシステムのビジネスニーズによって定義された機能的な変換と特定のプロトコル要件を提供するのは、Experience APIレイヤーです。

https://help.salesforce.com/articleView?id=apex_add_external_data_source.htm&type=5

説明
正解はA、C、Dです。これらは、Salesforce統合アーキテクトがプログラムの統合アーキテクチャのニーズを具体的に解決するために追求すべき3つの重要な詳細です。これらの詳細は、統合アーキテクトが統合ソリューションの範囲、要件、制約を理解し、適切なツール、手法、パターンを選択するのに役立ちます。詳細は以下の通りです。
ソースシステムとターゲットシステム、方向性、データ量と変換の複雑さ、そして活用可能なミドルウェア。これらの詳細は、統合アーキテクトが統合に関与するシステム、データフローの方向、交換されるデータの量と複雑さ、そして統合を促進できるミドルウェアまたはプラットフォームの機能を特定するのに役立ちます。
タイミングの側面 - リアルタイム/ニアリアルタイム（同期または非同期）、バッチ、更新頻度。これらの詳細は、統合アーキテクトが統合ソリューションのレイテンシ、信頼性、およびスケーラビリティの要件を決定し、適切な統合プロトコルと手法を選択するのに役立ちます。
統合スタイル - プロセスベース、データベース、仮想統合。これらの詳細は、統合アーキテクトがビジネスニーズと目標に適した統合スタイルを選択するのに役立ちます。
プロセス ベースの統合はシステム間でビジネス プロセスを調整することに重点を置き、データ ベースの統合はシステム間でデータを同期することに重点を置き、仮想統合はシステム間でデータの統一されたビューを提供することに重点を置いています。
参考資料: 認定 - 統合アーキテクト - Trailhead、[統合パターンとプラクティス]