CODEWITHSUNDEEP
oopdomain-driven-design
mgibas
mgibas

Reputation: 408

DDD: Where to put logic in aggregation root

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:

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. :

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:

  1. 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) ?
  2. 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.

Upvotes: 2

Views: 268

Answers (1)

jgauffin
jgauffin

Reputation: 101150

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/

Upvotes: 1

Related Questions