Domain Design crossing Aggregate Root Boundaries

Question

I'm a novice DDD'er and struggling with my first attempt to implement some of these concepts. I am writing an application to manage some marketing campaigns for different users, so a Campaign is an obvious aggregate root, but I also have Users as an aggregate root.

public class Campaign : IDomainObject
{
    public virtual int CampaignId { get; set; }
    public virtual string Name { get; set; }
    ...
    public virtual int UserId { get; set; }
    ...
    public virtual IList<CampaignEvent> Events { get; set; }
}

public class CampaignEvent
{
    public virtual int CampaignEventId { get; set; }
    public virtual int CampaignId { get; set; }
    public virtual int UserId { get; set; }
    ...
}

So now when I search for a list of campaigns to display, how do I get the User's name from the Id?

If I design the model with a database-agnostic perspective, I would add a UserName string to both objects and develop from there. However, I have to be practical and consider how this will eventually go back-and-forth to the database, and it doesn't appear that this new model will work with the ORM (presently NHibernate, but I don't believe this is possible with EF either).

What are some meet-in-the-middle solutions that will accomplish the goal of getting some user information available in the object, without compromising the concepts of DDD?

You're still thinking CRUD not DDD. Ignore db when modeling. — MikeSW
In a perfect 'modeled' world, I would include the UserName in both objects, and somehow tell the ORM to pull back the appropriate fields. Is this an ORM question and not a DB question? — Matt Murrell
@MikeSW - Thanks for helping me clarify my question. I've edited the original post to clearly describe my problem. — Matt Murrell

pragmatical pragmatical · Accepted Answer · 2014-05-12T23:23:11

I think the key here is that you want to change the thought process to entity to entity or value object relationships.

In the way you are modeling your classes, you have a UserId as a property and are talking about it as if it was a relationship. I think what you are wanting to convey is a relationship between the Campaign and a User, a CampaignEvent and a User, etc. It is perfectly acceptable for a Campaign to be an Aggregate Root and a User to be an Aggregate Root. When you search for a campaign, it will have a relationship to a User, so how you get the name is by getting the Name from the User entity. We don't want to speak about Id's alone, as this breaks our representation of the real entity we are trying to model. So a campaign has a/a collection user/users, and a user has a/a collection of campaign/campaigns, as opposed to a campaign has a userid.

Domain Design crossing Aggregate Root Boundaries

2 Answers