DDD saving "same" entity for different context boundaries

Question

This is only an example.

Say that you have 2 entities for 2 different context boundaries. The first context is the SkillContexter, the entity is 'Player' and has 3 properties: Id, Name and SkillLevel. In the other context (Contactcontext) the entity is 'Player' and has 3 properties: Id, Name and EMail.

How do I persist these entities to the database? I only want one table (Player) and not two tables (PlayerContact, PlayerSkill). Shall I have two different repositories for player that save the different context-entities, but into same table? Or shall I have a "master" player entity that holds all properties that I need to save, so that I create a new entity called PlayerMaster that has 4 properties: Id, Name, EMail and SkillLevel?

The first solution gives me more repositories, and the second makes me make a "technical" entity that only purpose is to save data to a database, and that feels really wrong, or is there a better solution that I have missed?

How have you guys solved it?

Answer 1

I'm not quite sure what you mean by context boundaries, so my answer may be off.

Do the two Player entities represent the same physical entity (person)? If so, then I would create a single Player entity with all four attributes and store their data in a single table.

Answer 2

When I first started with DDD, I also wrestled with the Context + Domain + Module + Model organization of things as well.

DDD is really meant to be a guide to building your domain models. Once I stopped trying to sub-organize my Contexts and boundies, and started thinking of what really is shared between entities - things started to fit together better.

I actually do not use contexts, unless it is a completely different application (app = context). Just my preference. But, I do have Modules that only share base abstracts and interfaces common throughout code (IRepository, IComponent, etc). The catch is, DDD says that Modules can share entities between modules - but, only on a very limited scale (you really don't want to do it often).

With that in mind, I would get away from using contexts and move to a "what really am I trying to accomplish, what do these models have in common). Here's what I would think, reading your question (if I understand them).

Person() is a base entity.  It has ID and Name.

PlayerSkill() is a Value Object, that is 
accessable from Person().PlayerSkill.

Contact() is an entity that inherits Person(), 
so it inherits ID and Name, and has additional Contact properties you want.

Now, I just tore up your domain. I know.

You can use a hybird approach as well:

Person() is a base entity.  It has ID and Name.

Player() inherits Person(), applies Skill()
and other VOs.

Contact() inherits Person(), applies Address()
and other VOs.