DDD сохраняя «одну и ту же» сущность для разных границ контекста - PullRequest
Новая
       9

DDD сохраняя «одну и ту же» сущность для разных границ контекста

4 голосов
/ 06 мая 2009

Это только пример.

Скажите, что у вас есть 2 сущности для двух разных границ контекста. Первый контекст - это SkillContexter, сущность «Player» и имеет 3 свойства: Id, Name и SkillLevel. В другом контексте (Contactcontext) сущность является «Player» и имеет 3 свойства: Id, Name и EMail.

Как мне сохранить эти объекты в базе данных? Я хочу только одну таблицу (Player), а не две таблицы (PlayerContact, PlayerSkill). Должен ли я иметь два разных репозитория для плеера, которые сохраняют разные контекстные сущности, но в одну таблицу? Или я должен иметь «мастерскую» сущность игрока, которая содержит все свойства, которые мне нужно сохранить, чтобы я создал новую сущность PlayerMaster, которая имеет 4 свойства: Id, Name, EMail и SkillLevel?

Первое решение дает мне больше репозиториев, а второе заставляет меня создать «техническую» сущность, единственной целью которой является сохранение данных в базе данных, и это кажется действительно неправильным, или есть лучшее решение, которое я пропустил?

Как вы, ребята, решили это?

Ответы [ 2 ]

5 голосов
/ 06 мая 2009

Когда я только начинал с DDD, я также боролся с организацией контекста + домен + модуль + модель.

DDD действительно предназначен для руководства по построению моделей вашего домена. Как только я перестал пытаться суборганизовать свои контексты и границы и начал думать о том, что на самом деле делится между сущностями - вещи стали лучше сочетаться.

Я на самом деле не использую контексты, если только это не совсем другое приложение (app = context). Просто мои предпочтения. Но у меня есть Модули, которые совместно используют только основные рефераты и интерфейсы, общие для всего кода (IRepository, IComponent и т. Д.). Суть в том, DDD говорит, что модули могут обмениваться объектами между модулями, но только в очень ограниченном масштабе (вы действительно не хотите делать это часто).

Имея это в виду, я бы отказался от использования контекстов и перешел к «что я на самом деле пытаюсь достичь, что общего у этих моделей). Вот что я думаю, читая ваш вопрос (если я понимаю их). 

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.

Теперь я просто порвал ваш домен. Я знаю.

Вы также можете использовать гибридный подход: 

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.
0 голосов
/ 06 мая 2009

Я не совсем уверен, что вы подразумеваете под контекстными границами, поэтому мой ответ может быть выключен.

Представляют ли два объекта Игрока один и тот же физический объект (лицо)? Если это так, то я бы создал единый объект Player со всеми четырьмя атрибутами и сохранил их данные в одной таблице.

...