Доменные обработчики событий - должны ли они использоваться для проблем прикладного уровня?
При реализации доменных событий обработчики событий должны использоваться только для чисто доменных задач; что-то, что вы бы обсудили с бизнес-экспертами, или они открыты для использования всем, кто интересуется моделью предметной области?
Это, скорее всего, лучше всего объяснить на простом примере, рассмотрим приложение Календарь для планирования работы сотрудников.
У нас могут быть следующие доменные события...
AppointmentAdded AppointmentRemoved AppointmentContentChanged AppointmentMoved
У нас есть обработчики для этих событий, например, когда Встреча переносится во время, выходящее за пределы рабочего времени сотрудников, мы устанавливаем флаг предупреждения.
Конечно, существуют опасения, связанные с этими событиями, например, когда в календарь добавляется Встреча, мы должны добавить ее в Единицу работы, чтобы мы могли зафиксировать изменения позже.
Должны ли эти проблемы приложений быть потребителями доменных событий, или мы должны вместо этого инициировать и обрабатывать отдельные системные события?
2 ответа
Существует два хорошо известных способа использования событий в решении DDD.
Первый основан на статьях Уди Дахана о событиях. Если вы еще не читали их, я настоятельно рекомендую это сделать. В итоге говорится, что вы публикуете свои события, используя статический класс в дополнение к обычному поведению в стиле ORM. Таким образом, вы добавляете заказ в коллекцию заказов клиента и публикуете событие. Поскольку поведение вашего домена выполняется внутри области транзакции, то же самое происходит и с обработчиками событий. Вы также можете найти там и совет не прикреплять объекты вручную к единице работы. Новые совокупные корни следует создавать, вызывая поведение существующих.
Есть еще один вариант, который предлагает Грег Янг. Он основан на источнике событий, который в основном использует события как средство сохранения состояния. При таком подходе ваши агрегатные корни обычно используют некоторую инфраструктуру (например, базовый агрегатный корневой класс) для применения событий. Apply вызывает обработчик событий для агрегатного корневого класса и публикует это событие на шине (независимо от используемой вами реализации шины).
Если вы имеете в виду сквозные проблемы, то вы все равно будете вынуждены использовать их, если этого требует логика вашего приложения. Так что он будет смешан с другим кодом обработки событий.
Но если вам нужно сделать несколько независимых вещей, когда произошло событие вашего домена, вам лучше использовать отдельные обработчики событий (см. Принцип разделения проблем).
Кстати, в первом случае старайтесь избегать смешения логики домена с логикой обработки событий (инфраструктуры). Оставленная инфраструктура / сквозные проблемы кода в обработчиках событий, вызывающих методы домена. Переместить код домена в методы объектов домена.