0

User を集約ルートとしてモデル化し、User は Identifier 値オブジェクトと Email 値オブジェクトで構成されます。どちらの値オブジェクトもユーザーを一意に識別できますが、電子メールは変更でき、識別子は変更できません。

私が見た DDD のほとんどの例では、集約ルートのリポジトリは識別子によってのみフェッチされます。電子メールでフェッチする別のメソッドをリポジトリに追加するのは正しいでしょうか? 私はこれをうまくモデリングしていませんか？

4

5 に答える 5

2

はい、リポジトリがID以外の方法で集計を取得する方法を持つことは適切です。ただし、注意すべき微妙な点がいくつかあります。

多くのリポジトリの例が ID によってのみ取得する理由は、集計の構造と結合されたリポジトリがすべてのクエリ要件を満たすことができないという観察に基づいています。たとえば、集計からいくつかのフィールドを呼び出し、参照された集計と集計データのいくつかのフィールドを呼び出すクエリがある場合、対応する集計クラスを使用してこのデータを表すことはできません。代わりに、専用の読み取りモデルが必要です。したがって、クエリの責任はリポジトリから切り離されます。これにはいくつかの利点があり (専用の非正規化ストアによってクエリを処理できます)、CQRSの主要なパラダイムです。. このタイプのアーキテクチャでは、何らかの動作を実行する必要がある場合にのみ、ドメイン クラスがリポジトリによって取得されます。すべての読み取り専用のユース ケースは、読み取りモデルによって提供されます。

リポジトリが GetByEmail メソッドを持つことが適切であると私が考える理由は、YAGNI と戦いの複雑さに基づいています。要件の変化や拡大に合わせてアプリケーションを進化させることができます。すぐに CQRS にジャンプして、読み取り/書き込みストアを分離する必要はありません。たまたまクエリメソッドもあるリポジトリから始めることができます。覚えておくべき唯一のことは、エンティティで何らかの動作を呼び出す必要がある場合は、ID でエンティティを取得する必要があるということです。

于 2012-12-08T21:36:23.537 に答える
0

この機能を、ユーザーオブジェクトに固有のサービス/ビジネスレイヤーに配置します。すべてのオブジェクトがEメール識別子を持つわけではありません。これは、リポジトリの責任というよりもビジネスロジックのように見えます。あなたはすでにこれを知っていると確信していますが、ここに私が話していることの良い説明があります。

これはお勧めしませんが、a GetByEmail(string emailAddress)メソッドを公開するユーザー用にリポジトリの特定の実装を作成することはできますが、それでもサービスのアイデアは気に入っています。

于 2012-12-08T14:26:05.147 に答える
0

電子メールでフェッチする別のメソッドをリポジトリに追加するのは正しいでしょうか? -私はそれをしません。私の意見では、リポジトリには ID による取得、保存、および削除のメソッドのみが必要です。

ユーザーをフェッチしてドメインメソッドを呼び出したいコマンドハンドラーにユーザーIDがない理由を尋ねたいと思います。あなたが何をしているのか正確にはわかりませんが、ログイン/登録のシナリオでは、次のようにします。ユーザーがログインすると、電子メールアドレスとパスワードが渡され、クエリを実行してユーザーを認証します-これはドメインまたはリポジトリを使用しませんが (コマンドのためだけです)、いくつかのクエリ実装を使用します。ユーザーIDを含むUserDto、この時点からユーザーIDを取得します。次のシナリオは登録です。新しいユーザーを作成するためのコマンド ハンドラーは、新しいユーザー エンティティを作成するため、ユーザーはログインする必要があります。

于 2012-12-09T22:42:38.927 に答える
0

私はeulerfxが答えたことに同意します：

ID 以外のものを使用して AR を取得する必要がある理由を自問する必要があります。

あなたがIDを持っていなくても、電子メールアドレスなどの他の一意の識別子を持っていることはかなり明白だと思います.

CQRS を使用する場合は、データがドメインにとって重要なのか、クエリ ストアだけにとって重要なのかを最初に判断する必要があります。データが 100% 一貫している必要がある場合は、状況が少し変わります。たとえば、一意の制約を満たすために電子メール アドレスが存在するかどうかを確認する場合、100% の一貫性が必要になります。クエリされたデータが常に古い場合、問題が発生する可能性があります。

リポジトリは、さまざまな種類のコレクションを表すことに注意してください。したがって、AR (コマンド側) で実際に操作する必要はないが、ドメインを使用している場所が適切であると判断した場合は、いつでもContainsEMailAddressリポジトリを使用できます。それ以外の場合、ドメイン データ ストア (OLTP タイプ ストア) は 100% 一貫性があるのに対し、クエリ ストア (OLAP タイプ ストア) は最終的に一貫性しかないため、ドメイン データ ストアのクエリ側も持つことができます。クエリ ストア。

于 2012-12-09T06:33:39.743 に答える
0

私が見た DDD のほとんどの例では、集約ルートのリポジトリは識別子によってのみフェッチされます。

あなたが見た例を知りたいです。DDD の定義によると、リポジトリは

オブジェクトのコレクションをエミュレートする、ストレージ、検索、および検索動作をカプセル化するためのメカニズム。

検索には明らかに、ID だけでなく、あらゆる種類の基準によるルートまたはルートのコレクションの取得が含まれます。

リポジトリは、 、 などに最適なGetCustomerByEmail()場所GetCustomersOver18()ですGetCustomersByCountry(...)。

于 2012-12-10T13:30:32.003 に答える