0

私は次のクラスを持っています：

class AggregateRoot
{
  // Defines common properties, Id, Version, etc.
}

class Container : AggregateRoot
{
  public IEnumerable<User> Users { get; }

  public void AddUser(User newUser)
  {
    // ...
  }

  // ...
}

class User
{
  public void AddNotification(Notification newNotification)
  {
    // ...
  }

  // ...
}

class Notification
{
  public string Message { get; set; }
}

ご覧のとおり、1 人以上のユーザーを含むコンテナーがあり、各ユーザーは 0 個以上の通知を送信できます。

このシナリオで最も一般的な操作は、新しい通知を追加することなので、ユーザーを頻繁に取得します。コンテナーからユーザーを取得することは可能ですが、その場合、コンテナー オブジェクトを取得して、ユーザー コレクションを検索する必要があります。コンテナが非常に小さくて新しい場合は問題ありません。しかし、コンテナが古くなるにつれて、より多くのユーザーを獲得します。そのため、Users コレクションは非常に大きくなる可能性があります。私の問題は、User クラスが疑似集約ルートであり、User に対して多くの操作が行われますが、User は Container の外に存在できないことです。ユーザーを格納する新しいリポジトリで明らかなパフォーマンスの問題を解決すると、別の問題が発生します。ユーザー リポジトリ内のユーザーとコンテナ内のユーザーの同期を維持するにはどうすればよいですか?

ユーザー ID だけをコンテナー クラスに格納することもできますが、特定のプロパティを参照できなくなるため、新しいユーザーをコンテナーに追加する際のビジネス ロジックが不要になります。それで、どうすればいいですか？

イベントを保存するためにMongoDbを使用しています。

4

1 に答える 1

3

ユーザーを格納する新しいリポジトリで明らかなパフォーマンスの問題を解決すると、別の問題が発生します。ユーザー リポジトリ内のユーザーとコンテナ内のユーザーの同期を維持するにはどうすればよいですか?

少し異なる方法でモデルを実装できます。唯一の動作がインスタンスContainerの追加である場合は、集約も作成できます。ユーザーがコンテナーの一部でなければならないという制約を表すために、ユーザーは ID でコンテナーを参照できます。UserUser

class User
{
  public int ContainerId { get; private set; }
  public void AddNotification() //...
}

Container クラスは、ユーザーの追加に関連するいくつかの動作を引き続き提供できます。たとえば、新しいユーザーを作成するためのファクトリ メソッドを提供できます。これは、ユースケースを実装するアプリケーション サービスによって使用されます。

class Container
{
  public int Id { get; private set; }
  public User CreateUser(string userName)
  {
    return new User(this.Id, userName);
  }
}

class UserAppService
{
  public void AddUserToContainer(int containerId, string userName)
  {
    var container = this.containerRepository.Get(containerId);    
    var user = container.CreateUser(userName);    
    this.userRepository.Add(user);
  }
}

この実装では、Container はユーザーのコレクションを保存しません。これは、ご指摘のとおり、コレクションが非常に大きくなり、メモリ内で管理できないためです。MongoDB には、コンテナー コレクションとユーザー コレクションがあります。

この「疑似集約ルート」の概念に遭遇するときはいつでも、おそらく関連する 2 つの集約がある可能性があります。これは、この種の問題を解決するための一般的な戦術です。この件に関する詳細な説明については、Vaughn Vernon による「Effective Aggregate Design 」を参照してください。

于 2012-10-15T17:33:14.630 に答える