12

DDD の一意性のチェックについて質問があります。スタックオーバーフローでこれについていくつか質問があることは知っていますが、私の疑問に実際には答えていません

データベースへの更新/挿入時に一意性をチェックするために、集約ルートがリポジトリの参照を保持することは可能ですか? それとも、これはドメイン モデルではなく、アプリケーション サービスによって実行されるタスクですか?

ユーザー登録時にユーザーモデルのユーザー名が一意かどうかを確認したいとしましょう。考えられるいくつかのアプローチがあります。

  • ユーザー モデル参照 UserRepository、Validate() で一意性チェックを行う
  • UserRepository を使用して、一意性チェックを行うドメイン サービスを作成します (通常、ロジックが複数のドメイン モデルにまたがる場合にのみドメイン サービスが使用されると思うので、これは少し奇妙に思えます)。
  • UserRepository を参照してドメイン層に仕様オブジェクトを作成し、一意のチェック規則をカプセル化し、アプリケーション サービス層はこれを使用して更新/挿入前にチェックを行います

また、依存性注入を使用する場合、アプローチ 1 で UserRepository をユーザーに注入する方法、アプローチ 2 でドメイン サービスを注入する方法、またはアプローチ 3 でアプリケーション サービスを注入する方法についてまだ疑問に思っています。 、オブジェクトを手動でインスタンス化する必要があるため、IoCでサービスロケーターを使用してインスタンスを取得する唯一のオプションがあるようです。でもサービスロケーターはアンチパターンなので避けたい

サンプルコードは大歓迎です

4

1 に答える 1

10

一意性のチェックはリポジトリの責任になると思います。リポジトリは、ドメイン コレクションをシミュレートすることを想定しているため、すべての集計を認識しているため、リポジトリに一意性を要求するのは自然なことです (たとえば、HashMap から期待されるように)。

// repository
interface Users {
  // implementation executes SQL COUNT in case of relation DB
  bool IsNameUnique(String name);

  // implementation will call IsNameUnique and throw if it fails
  void Add(User user);
}

マルチユーザー環境では、これをデータストア側で強制する必要があるため（UNIQUE SQL制約、またはロックなど）、ある意味では漏れやすい抽象化です。

IsNameUnique はおそらく User 集計から呼び出されるべきではありません。アプリケーションの残りの部分がどのように構成されているかに応じて、この呼び出しをアプリケーションまたはドメイン サービスに移動します。

別のアプローチについては、「CQRS アーキテクチャでの一意性の検証」を参照してください。

于 2013-05-30T23:17:17.920 に答える