DDD: Où mettre la logique dans la racine d'agrégation

Question

Toujours en train d'expérimenter avec DDD et avoir quelques doutes, peut-être que quelqu'un m'aiderait.

Disons que j'ai 2 modèles:

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

public class User {} 

Mon problème est que je ne vois pas de place pour la logique que je veux mettre en œuvre. J'ai besoin 3 actions:

• événement join utilisateur
• événement congé utilisateur
• Creator supprimer l'utilisateur de l'événement (seul Créateur peut supprimer des utilisateurs)

Pour l'instant, je viens de créer un service de domaine EventUserService qui appelle Event.RemoveUser/AddUser et ie. vérifie si CurrentUser (fourni par UserService) est le créateur de l'événement (avoir le droit de supprimer d'autres utilisateurs). Peut-être que cette approche est correcte, mais je pense toujours que je devrais mettre cette logique dans les racines d'agrégation, à savoir. :

• User.JoinEvent (Evénement) - Je peux ajouter un événement passé à la collection User.Events (bidirectionall) sur une certaine logique. User.LeaveEvent (Event) - analogue à JoinEvent.
• User.RemoveUserFromEvent (Utilisateur, événement) - Je peux avoir CreatedEvents collection utilisateur et événement de cette collection, je peux appeler Event.RemoveUser (utilisateur) - cette façon, je veillerai à ce que seul le créateur peut botter quelqu'un. Ou
• Evet.RemoveUser (UserToRemove) - mais comment vais-je m'assurer qu'il est appelé par le créateur?

Si la première méthode à deux semble ok (au moins pour moi), 3ème créerait Event.RemoveUser (pour gérer la collecte des membres de l'événement) méthode qui pourrait être utilisé à la logique de dérivation résidant dans User.RemoveUserFromEvent .

Ainsi, à la fin j'ai 2 questions:

1. Quelle est votre approche dans ce genre de situation où deux racines d'agrégation travaille ensemble et une opération est de déterminer par une logique résidant dans les deux? Peut-être une sorte de methoods comme User.CanJoinEvent (Event)?
2. Qu'en est-il créer le point de « danger » comme User.RemoveUserFromEvent

Peut-être que quelqu'un peut putt un peu de lumière peu sur cela pour moi, toute l'aide serait bien.

Answer 1

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

Ne faites pas cela.Vous enfreignez la loi de Demeter et la classe Event n'a aucun contrôle sur les changements dans Members ou les utilisateurs dans cette liste. Vous devez à la place définir des méthodes dans la classe Event utilisée pour gérer les membres.

Maintenant, si vous faites ce changement, à savoir quelque chose comme ceci:

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

Vous aurez tout à coup des endroits solides pour générer les événements.

mais comment je vais m'assurer que c'est appelé par le créateur?

En .NET, vous pouvez utiliser Thread.CurrentPrinicpal pour obtenir des informations sur l'utilisateur connecté. Il nécessite cependant que vous implémentez votre propre IPrincipal/IIdentity. N'oubliez pas: Vous devez TOUJOURS vous assurer que les modèles sont dans un état valide dans DDD. Cela signifie généralement que tous les setters doivent être privés: http://blog.gauffin.org/2012/06/protect-your-data/