Каждый из bounding context'ов генерирует определенный набор событий, чтобы корректно связать несколько контекстов, нужно подписаться на событие определенного контекста и вызвать в другом контексте какое-то действие.
Возникают вопросы:
Где осуществялется подписка на событие? В инфраструктурном слое приложения?
Что должен вызывать обработчик события в другом контексте? Application сервис или может дернуть Domain сервис на прямую?
glagola писал(а): ↑2017.06.02, 18:54
[*] Где осуществялется подписка на событие? В инфраструктурном слое приложения?
Да. Например, контроллеры это инфраструктура (ui). Подписчик тоже будет инфраструктурой, через которую сообщения попадают в домен.
glagola писал(а): ↑2017.06.02, 18:54
[*] Что должен вызывать обработчик события в другом контексте? Application сервис или может дернуть Domain сервис на прямую?
Я думаю можно и то и другое. Если у вас прикладная служба получается пустой, просто делегирует вызов к модели, ее создавать незачем. Можно напрямую модель вызвать.
glagola писал(а): ↑2017.06.02, 18:54
[*] Где осуществялется подписка на событие? В инфраструктурном слое приложения?
Да. Например, контроллеры это инфраструктура (ui). Подписчик тоже будет инфраструктурой, через которую сообщения попадают в домен.
glagola писал(а): ↑2017.06.02, 18:54
[*] Что должен вызывать обработчик события в другом контексте? Application сервис или может дернуть Domain сервис на прямую?
Я думаю можно и то и другое. Если у вас прикладная служба получается пустой, просто делегирует вызов к модели, ее создавать незачем. Можно напрямую модель вызвать.
Пока сделал так, что подписчик на событие дергает исключительно application service другого bounding context'а. После экспериментов это показалось правильно, так как подписчик, будучи инфраструктурой, должен взаимодействовать только со слоем приложения.