rest - 外部データ ソースをリポジトリ パターンにカプセル化する

Question

新しいサービスのハイレベルなデザインを作成しています。サービスの複雑さは、DDD を使用することを保証します (私は思います)。そこで、従来の方法でドメイン サービス、集計、リポジトリなどを作成しました。リポジトリはデータ ソースをカプセル化します。したがって、クエリはキャッシュ内のオブジェクトを検索できます。データベース内の検索に失敗すると、オブジェクトの作成に失敗します。REST必要な情報を取得するために外部サービスを呼び出します。これはかなり標準的です。私の同僚は、リポジトリを使用する開発者が API の実行に必要な時間を認識できず、その結果、API の実行時間を計算できないため、この方法でデータ ソースを抽象化することは危険であるという主張を提唱しています。その上に書いています。自分の呼び出しが呼び出しになることを知っていれば、コンポーネントの動作を別の方法で設定したいと思うかもしれませんREST。彼らは私が移動することを提案していますRESTリポジトリの外部で呼び出し、場合によってはキャッシュ戦略も一緒に呼び出します。彼らの言いたいことはわかりますが、リポジトリ パターンの背後にある全体的な考え方は、まさにこの種の情報を隠し、各コンポーネントにキャッシュ戦略とデータ アクセスを処理させないようにすることです。私の質問は、この懸念に対処するパターンまたはモデルはありますか?

Answer 1

彼らは、REST 呼び出しをリポジトリの外に移動することを提案しています

その後、リポジトリはありません。リポジトリは、永続性の詳細がわからないことを意味しますが、永続性があることを知らないということではありません。リポジトリを使用するたびに、その実装 (メモリ内リストから REST 呼び出しまで) に関係なく、「遅い」ことが予想されます。これは、通常、永続性がボトルネックであることはよく知られているためです。

特定のリポジトリ実装 (REST ベースなど) を使用する人は、それがレイテンシーや一時的なエラーに対処できることを知っているでしょう。依存関係だけを持つサービスIRepositoryは、永続性を扱うことを認識しています。

キャッシング戦略については、いくつかのサービス レベル (より一般的な) キャッシングとリポジトリ レベル (持続性固有) キャッシングを使用できます。これらはおそらく実装の詳細です。

私の同僚は、この方法でデータ ソースを抽象化することは危険であると主張しています。なぜなら、リポジトリを使用している開発者は、API の実行に必要な時間を認識できず、その結果、API の実行時間を計算できないからです。その上に書いています。自分の呼び出しが REST 呼び出しになることを知っていれば、コンポーネントの動作を別の方法で設定したいと思うかもしれません。

これはあなたの人生を複雑にしようとして時間を無駄にしています. 抽象化の要点は、汚れた詳細を隠すことです。彼らが提案するのは基本的には、ユーザーに実装の詳細を認識させて、ユーザーがそのコードをそれに結合できるようにすることです。

ポイントは、開発者は使用している API を認識している必要があるということです。コンポーネントが外部サービス (db、web サービス) を使用している場合、これを知っておく必要があります。取得するデータがあることがわかったら、それを待つ必要があることがわかります。

DDD ルートを使用する場合は、境界付けられたコンテキスト (BC) があります。別の BC に依存するモデルを作成することは、非常に悪い考えです。各 BC はドメイン イベントを発行する必要があり、関心のある各 BC はサブスクライブして、それらのイベントに基づいて独自のモデルを維持する必要があります。これは、クエリが「ローカル」になることを意味しますが、それでもデータベースにヒットします。

Answer 2

リポジトリ パターンは、永続層との結合を減らすことを目的としています。私の意見では、リポジトリをこれほどまでに責任のあるものにする危険はありません。

外部サービスの変更に対して Anti Corruption Layer を使用し、プロキシを使用してキャッシュ関連の問題を隠すことができます。

次に、アプリケーション層でフォールバック戦略をコーディングします。

Answer 3

それはすべて、フェッチ/フォールバック戦略がサービス層またはインフラストラクチャ層のどこに属していると考えるかにかかっていると思います (私には後者の方がより正当に聞こえます)。

2 つが混在している可能性もあります。サービスには、障害が発生した場合に順番に使用される一連のリポジトリが渡されます。一連のリポジトリの構築は、インフラストラクチャ層または他の場所に配置できます。ある場所ではフォールバック ロジック、別の場所ではフォールバック構成。

余談ですが、非同期は、何かが遅くなる可能性があり、それを待つとブロックされる可能性があることをユーザーに知らせる良い方法のようです。バニラの目立たないリポジトリ名の後ろにすべてを隠すよりも、タイプ IMO に「これは遅い可能性があります」という大きな脅迫的なプレフィックスを追加するよりも優れています。