DDD: Where to put logic in aggregation root - oop

Question

Still experimenting with DDD and have some doubts, maybe someone would help me.
Lets say that I have 2 models:
public class Event
{
User Creator;
List<User> Members;
}
public class User {}
My problem is that I cannot see place for logic that I want to implement. I need 3 actions:
User join event
User leave event
Creator remove user from event (only Creator can remove users)
For now I just created domain service EventUserService that calls Event.RemoveUser/AddUser and ie. checks if CurrentUser (provided by UserService) is creator of event (have rights to remove other users).
Maybe that approach is ok, but I still feel that I should putt that logic into aggregation roots, ie. :
User.JoinEvent(Event) - i can add passed Event to User.Events collection (bidirectionall) base on some logic.
User.LeaveEvent(Event) - analogous to JoinEvent.
User.RemoveUserFromEvent(User,Event) - I can have CreatedEvents collection in User and for Event from that collection I can call Event.RemoveUser(User) - this way I will make sure that only creator can kick someone.
Or
Evet.RemoveUser(UserToRemove) - but how I will make sure that its called by creator ?
If first two method looks ok (at least for me), 3rd one would create Event.RemoveUser (to manage Event members collection) method that could be used to bypass logic residing in User.RemoveUserFromEvent.
So, in the end I have 2 questions:
What is your approach in situation like this where two aggregation roots works together and one operation is determine by logic residing in both of them? Maybe some kind of methoods like User.CanJoinEvent(Event) ?
What about creating "danger" point like User.RemoveUserFromEvent
Maybe someone can putt a little bit light on that for me, every help would be nice.

Answer 1

public class Event
{
User Creator;
List<User> Members;
}
Don't do that. You are breaking Law Of Demeter and the Event class has no control over the changes in Members or the users in that list. You should instead define methods in the Event class which is used to handle the members.
Now, if you do that change, i.e. have something like this:
public class Event
{
User Creator { get private set; }
bool IsMember(string name);
void AddMember(User user);
}
You'll suddenly have solid places to generate the events.
but how I will make sure that its called by creator ?
In .NET you can use Thread.CurrentPrinicpal to get information about the logged in user. It do however require that you implement your own IPrincipal/IIdentity.
Remember: You should ALWAYS make sure that the models are in a valid state in DDD. That usually means that all setters should be private: http://blog.gauffin.org/2012/06/protect-your-data/