Моделирование графика с DDD - PullRequest
2 голосов
/ 28 ноября 2011

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

Домен состоит из объекта Show, представляющего одну выставку, выставку или конференцию, где мы можем продвигать наши продукты. У него есть даты и время начала и окончания, повестка дня, список выступающих, местоположение и т. Д. С помощью Шоу можно проделать немалую работу, такую ​​как назначение выступающих, регистрация участников, отмена и т. Д.

Мы обычно участвуем в Шоу в рамках одной или нескольких маркетинговых кампаний. Кампания также имеет даты начала и окончания и другую информацию, а также список Шоу, которые мы посетим для этой Кампании. Вполне возможно, что мы будем продвигать более одной кампании на данном шоу.

Шоу могут быть добавлены или удалены из Кампаний, а когда Шоу отменено, оно должно быть удалено из любых Кампаний, с которыми оно было связано.

Моей первой мыслью было создание сводного корня Schedule со списком сущностей Campaign, который содержал список объектов Show. Но мне нужен способ доступа к автономным шоу - и шоу может быть связано с несколькими кампаниями.

Глядя на мои варианты использования, я разрабатываю клиент Silverlight (но, возможно, также стану мобильным). Основным представлением будет пользовательский интерфейс календарного типа (например, Outlook), который отображает каждое шоу как встречу. Есть также боковые панели, которые отображают Предстоящие шоу, Текущие кампании и Шоу, которые имеют последующие задачи. Когда я дважды щелкаю элемент в любом из этих представлений, подробности Показать отображаются в дочернем окне.

Любые предложения, как смоделировать этот домен в коде моего приложения?

1 Ответ

3 голосов
/ 30 ноября 2011

Но мне нужен способ доступа к автономным Шоу - и Шоу может быть связано с несколькими кампаниями.

Вместо того, чтобы пытаться поместить все в сводный корень расписания (термин, который не появляется в вашем языке, когда вы говорите о домене свободно), попробуйте иметь 2 совокупных корня - Показать и Кампания.

Кампания также имеет даты начала и окончания и другую информацию, а такжесписок Шоу, которые мы будем посещать для этой Кампании.

Возможно, для Кампании нет необходимости хранить ссылку на Шоу.Если шоу знает Кампании, которые оно продвигает, этого достаточно, чтобы найти его, когда вы будете отображать информацию Кампании.

Шоу можно добавлять или удалять из Кампаний, а когда Шоу отменяется, оно должно быть удалено излюбые кампании, с которыми он был связан.

Нет, он не должен .
Показ должен быть помечен как отмененный, и кампании просто скрыли бы его при необходимости.

Я бы начал с чего-то вроде this .


Только из-за моей попытки быть кратким, Расписание не было введено, пока я не начал обсуждать модель.На самом деле, График это весь смысл приложения.Расписание представляет все Шоу.

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

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

Если Show должен существовать в «автономной версии», это совокупный корень (нажатие на него под Schedule ничего не изменит, это просто добавит еще один слой абстракции. Show все равно будетнезависим от кампаний).Если необходимо выяснить, с каким Campaign / s Show связано то время, которое отображается как в «автономной версии», должна быть ассоциация Show-> Campaigns.Несмотря на то, что это может показаться немного противоречащим предметной области, вы можете рассматривать это как жертву.

Мы торгуем способностью выражать себя с ясностью оригинальной идеи ( Принцип неопределенности можно использовать какотличная аналогия здесь).В конце концов - в любом случае мы не можем полностью и тщательно отразить ментальные модели.

Логически я согласен с вашей точкой зрения, но я также хотел бы убедиться, что все члены Кампании разделяют только один экземпляр.Показывает, что ему присвоено.

Вам следует немного сосредоточиться на жизненном цикле доменных объектов.

Существует огромная разница между строительством и реконструкцией объекта.Как правило, Campaign создается только один раз, после этого - только из хранилища данных.Если вы гарантируете, что разные экземпляры одной и той же Campaign (с точки зрения домена) не могут быть сохранены дважды - обычно этого достаточно.

Это то, что привело меня к моей первоначальной мысли, что Campaign была корнем, но делаетпоэтому игнорирует реальность того, что будут Шоу, которые не являются частью Кампании.

Да ... Вы правы в этом.

...