DDD saves the “same” object for different context boundaries

Question

This is just an example.

Say that you have 2 objects for two different context boundaries. The first context is SkillContexter, the entity is "Player" and has 3 properties: Id, Name and SkillLevel. In another context (Contactcontext), the object is "Player" and has 3 properties: Id, Name and EMail.

How to save these objects in a database? I need only one table (Player), and not two tables (PlayerContact, PlayerSkill). Should I have two different repositories for a player that store different context objects, but in the same table? Or do I have a “main” game object that contains all the properties that I need to save in order to create a new object called PlayerMaster, which has 4 properties: Id, Name, EMail and SkillLevel?

The first solution gives me more repositories, and the second forces me to create a “technical” object that is only intended to store data in the database, and is this really wrong, or is there a better solution that I missed?

How did you guys decide that?

Answer 1

When I first started working with DDD, I also struggled with organizing Context + Domain + Module + Model.

DDD is really designed to create models of your domain. As soon as I stop trying to subordinate my Contexts and faces, and began to think about what really is shared between entities, everything became better combined.

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

With this in mind, I avoid using contexts and move on to "what I'm really trying to do, what these models have in common." Here is what I think when 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 ripped your domain. I know.

You can also use the hybird approach:

 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. 

Answer 2

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

Do two players of a player share the same physical object (person)? If so, then I would create a separate Player object with all four attributes and save their data in one table.