CODEWITHSUNDEEP
domain-driven-design
Magnus Gladh
Magnus Gladh

Reputation: 1877

DDD saving "same" entity for different context boundaries

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?

Upvotes: 5

Views: 3370

Answers (2)

eduncan911
eduncan911

Reputation: 17604

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.

Upvotes: 6

Jamie Ide
Jamie Ide

Reputation: 49261

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.

Upvotes: 3

Related Questions