What about link tables in domain-driven-design?

Question

In the book .NET Domain-Driven Design with C# from Tim McCarthy there's an example of a link table (two foreign keys + one boolean column) that gets it's own class in the domain. Is this common?

The example is a Contact table and a Project table. The link table is a ProjectContact. What are the pros and cons of using a class ProjectContact instead of having a List of Contacts property in the Project class and a List of Projects property in the Contact class?

I must say that having a ProjectContact class makes it easy to persist a new link between a Project and a Contact... but it seems overkill to me.

Answer 1

Pragmatically spoken (I'm not a DDD expert), I would say that a link table shouldn't pop up in the domain unless it is an entity on it's own (i.e. you need to attach behaviour to it, or it has properties other than the foreign keys).