リポジトリを使用してデータベースと通信するシステムがあります。リモートサービスの正しい定義は?またはより良い、
[...] は外部 Web サービス用であるため、リポジトリはデータベース用です。
ServiceAgents について多くの場所で見つけましたが、これが正しい定義かどうかはわかりません。
リポジトリを使用してデータベースと通信するシステムがあります。リモートサービスの正しい定義は?またはより良い、
[...] は外部 Web サービス用であるため、リポジトリはデータベース用です。
ServiceAgents について多くの場所で見つけましたが、これが正しい定義かどうかはわかりません。
DDDでは、リポジトリはエンティティの仮想コレクション(特に集約ルート)を表します。したがって、10Mの永続的な顧客がいる場合は、メモリ内のすべての10Mのコレクションであるかのようにリポジトリを操作します。リポジトリは通常、コレクションで見られるのと同じタイプの操作(何かを追加する、何かを削除する、コレクションで何かを見つける)のみを処理します。
データの実際の永続性がWebサービスを介して発生する場合、リポジトリの実装はデータベースではなくWebサービスプロキシと対話する可能性があります。ただし、永続性にWebサービスが含まれるという事実は、ドメインでの永続性の表現方法を左右するものではありません。つまり、データが直接データベース呼び出し、ORM、Webサービス、または伝書鳩を介して永続化されるかどうかは、実装の詳細です。
これで、ドメインモデルに外部サービス(クレジットカードの検証、アドレスの検証など)によって促進される依存関係がある場合、これは、必要な操作を定義するインターフェイスの形式でドメインサービスとして表現する必要があります。ドメインモデル。明確にするために、ドメインサービスは、論理的にはドメインの一部であるが、何らかの理由で特定のエンティティまたは値オブジェクトに完全に適合しない操作です。外部サービスによって促進される動作は、ドメインサービスを使用する場合のほんの一例であるため、ドメインサービスを「Webサービスのリポジトリパターン」などとは考えないでください。
私はDDDの原則のほとんどに頭を悩ませているだけですが、リポジトリは一般にデータベースを抽象化するために使用されますが、永続的および/またはクエリ可能なストアとして動作するものをラップするために使用できることを理解しています。つまり、私が提案しているのは、サービスがデータベースのように十分に動作する場合、リポジトリを使用して、処理するエンティティへのアクセスを抽象化することに問題はないということです。
それ以外の場合、Webサービスがドメイン内のデータや動作を直接処理しない場合は、おそらくあなたのケースがアプリケーション層のインフラストラクチャレベルのサービスの候補になる可能性があります。
誰かが異議を唱えている場合は、私自身がリポジトリの使用目的を誤解していないかどうか知りたいので、コメントしてください。
これが正式な用語かどうかはわかりませんが、これを「サービス プロキシ」と呼びます。