How to handle properties that exist “between” entities (in a many-to-many relationship in this case)?

Question

I've found a few questions on modelling many-to-many relationships, but nothing that helps me solve my current problem.

Scenario

I'm modelling a domain that has Users and Challenges. Challenges have many users, and users belong to many challenges. Challenges exist, even if they don't have any users.

Simple enough. My question gets a bit more complicated as users can be ranked on the challenge. I can store this information on the challenge, as a set of users and their rank - again not too tough.

Question

What scheme should I use if I want to query the individual rank of a user on a challenge (without getting the ranks of all users on the challenge)? At this stage, I don't care how I make the call in data access, I just don't want to return hundreds of rank data points when I only need one.

I also want to know where to store the rank information; it feels like it's dependent upon both a user and a challenge. Here's what I've considered:

1. The obvious: when instantiating a Challenge, just get all the rank information; slower but works.

2. Make a composite UserChallenge entity, but that feels like it goes against the domain (we don't go around talking about "user-challenges").

   

3. Third option?

I want to go with number two, but I'm not confident enough to know if this is really the DDD approach.

Update

I suppose I could call UserChallenge something more domain appropriate like Rank, UserRank or something?

Answer 1

The DDD approach here would be to reason in terms of the domain and talk with your domain expert/business analyst/whoever about this particular point to refine the model. Don't forget that the names of your entities are part of the ubiquitous language and need to be understood and used by non-technical people, so maybe "UserChallenge" is not he most appropriate term here.

What I'd first do is try to determine if that "middle entity" deserves a place in the domain model and the ubiquitous language. For instance, if you're building a website and there's a dedicated Rankings page where the user he can see a list of all his challenges with the associated ranks, chances are ranks are a key matter in the application and a Ranking entity will be a good choice to represent that. You can talk with your domain expert to see if Rankings is a good name for it, or go for another name.

On the other hand, if there's no evidence that such an entity is needed, I'd stick to option 1. If you're worried about performance issues, there are ways of reducing the multiplicity of the relationship. Eric Evans calls that qualifying the association (DDD, p.83-84). Technically speaking, it could mean that the Challenge has a map - or a dictionary of ranks with the User as a key.

Answer 2

I would go with Option 2. You don't have to "go around talkin about user-challenges", but you do have to go around grabbin all them Users for a given challenge and sorting them by rank and this model provides you a great way to do it!