Доменные обработчики событий - должны ли они использоваться для проблем прикладного уровня? - PullRequest
7 голосов
/ 08 января 2011

При реализации событий домена следует использовать обработчики событий только для чисто доменных задач;что-то, что вы могли бы обсудить с бизнес-экспертами, или они открыты для использования всем, кто интересуется моделью предметной области?

Это, скорее всего, лучше всего объяснить на простом примере, рассмотрим приложение Календарь дляпланирование работы для сотрудников.

У нас могут быть следующие доменные события ...

AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved

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

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

Должны ли эти проблемы приложения быть потребителями событий домена, или мы должны вместо этого инициировать и обрабатывать отдельные системные события?

Ответы [ 2 ]

5 голосов
/ 14 января 2011

Существует 2 хорошо известных способа использования событий в решении DDD.

Первый основан на статьях Уди Дахана о событиях . Если вы еще не читали их, я настоятельно рекомендую это. В итоге говорится, что вы публикуете свои события, используя статический класс в дополнение к нормальному поведению в стиле ORM. Таким образом, вы добавляете заказ в коллекцию заказов клиентов и вы публикуете событие. Поскольку поведение вашего домена выполняется внутри области транзакции, то же самое происходит и с обработчиками событий. Вы также можете найти там и совет не прикреплять объекты вручную к единице работы. Новые совокупные корни следует создавать, вызывая поведение существующих.

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

2 голосов
/ 11 января 2011

Если вы имеете в виду сквозные проблемы, то вам все равно придется его использовать, если этого требует логика вашего приложения.Таким образом, он будет смешан с другим кодом обработки событий.

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

Кстати, в первом случае старайтесь избегать смешения логики домена с логикой обработки событий (инфраструктуры).Оставленная инфраструктура / сквозные проблемы кода в обработчиках событий, вызывающих методы домена.Переместить код домена в методы объектов домена.

...