2

まだ DDD を試していて、疑問がある場合は、誰かが私を助けてくれるかもしれません。

私は2つのモデルを持っているとしましょう：

public class Event
{
    User Creator;
    List<User> Members;
}

public class User {}

私の問題は、実装したいロジックの場所が見えないことです。3つのアクションが必要です:

  • ユーザー参加イベント
  • ユーザー退会イベント
  • 作成者はイベントからユーザーを削除します (作成者のみがユーザーを削除できます)

今のところ、 Event.RemoveUser/AddUserを呼び出すドメイン サービスEventUserServiceを作成しました。CurrentUser ( UserServiceによって提供される) がイベントの作成者であるかどうかを確認します (他のユーザーを削除する権限を持っています)。おそらくそのアプローチは問題ありませんが、そのロジックを集約ルートに入れる必要があると感じています。:

  • User.JoinEvent(Event) - いくつかのロジックに基づいて、渡された Event を User.Events コレクション (双方向) に追加できます。
  • User.LeaveEvent(Event) - JoinEvent に似ています。
  • User.RemoveUserFromEvent(User,Event) - CreatedEventsコレクションをUserに持つことができ、そのコレクションのEventに対してEvent.RemoveUser(User)を呼び出すことができます。このようにして、作成者だけが誰かをキックできるようになります。または
  • Evet.RemoveUser(UserToRemove) - しかし、作成者によって呼び出されたことを確認するにはどうすればよいですか?

最初の2つのメソッドが（少なくとも私にとっては）問題ないように見える場合、3番目のメソッドはEvent.RemoveUser（イベントメンバーコレクションを管理するため）メソッドを作成し、 User.RemoveUserFromEventにあるロジックをバイパスするために使用できます。

だから、最後に私は2つの質問があります：

  1. このような 2 つの集計ルートが連携し、両方に存在するロジックによって 1 つの操作が決定されるような状況では、どのようなアプローチをとっていますか? 多分User.CanJoinEvent(Event)のようなある種の方法ですか？
  2. User.RemoveUserFromEventのような「危険」ポイントを作成するのはどうですか

多分誰かが私のためにそれについて少し光を当てることができます、すべての助けがいいでしょう.

4

1 に答える 1

1 
public class Event
{
    User Creator;
    List<User> Members;
}

そうしないでください。あなたはデメテルの法則に違反しており、EventクラスはMembersそのリストの変更またはユーザーを制御できません。Event代わりに、メンバーを処理するために使用されるクラスでメソッドを定義する必要があります。

ここで、その変更を行うと、つまり次のようになります。

public class Event
{
    User Creator { get private set; }
    bool IsMember(string name);
    void AddMember(User user);
}

イベントを生成するためのしっかりした場所が突然できます。

しかし、作成者によって呼び出されることを確認するにはどうすればよいですか?

.NET ではThread.CurrentPrinicpal、ログインしているユーザーに関する情報を取得するために使用できます。IPrincipalただし、独自の/を実装する必要がありますIIdentity。

注意: モデルが DDD で有効な状態であることを常に確認する必要があります。これは通常、すべてのセッターを非公開にする必要があることを意味します: http://blog.gauffin.org/2012/06/protect-your-data/

于 2012-09-11T05:46:17.020 に答える