Ваш вопрос касается архитектуры, управляемой сообщениями, которая работает вместе с CQRS, но не связана с ней.
В любом случае, ваша диаграмма почти верна. Подписчик/обработчик событий (я предпочитаю эту терминологию) может отправлять новые команды через служебную шину, но это не правило, согласно которому вы должны всегда делать это. Я реализую довольно много функций непосредственно в обработчике событий, хотя, вероятно, было бы более чисто и надежно отправить новую команду. Это действительно зависит от того, что я хочу делать.
Обратите внимание, что обработчики сообщений (команды или события) не должны знать о других обработчиках. Они должны знать об автобусе, а автобус позаботится об управлении. Это означает, что в вашем приложении обработчики событий будут принимать шину как зависимость, создавать команду и отправлять ее через шину. Сам обработчик событий не знает, какой обработчик команд сгенерировал событие, и может «ответить» на него.
Обычно команды обрабатываются независимо, и вы не можете гарантировать порядок (если только они не обрабатываются синхронно), поэтому, возможно, вы хотите, чтобы вторая команда была выдана в результате обработки первой команды. Действительно, это может быть случай для саги.
Насколько я знаю, вы говорите только о том, чтобы делать что-то синхронно, поэтому ваш подход работает в этом случае, но, вероятно, он не масштабируется. Переход к асинхронной обработке нарушит этот поток выполнения. Однако ваше приложение может с этим справиться, не все должно быть твиттером.
Архитектура, управляемая сообщениями, не так проста, и в некоторых случаях (например, вам нужен немедленный ответ от серверной части) ее довольно сложно реализовать, по крайней мере, сложнее, чем при «стандартном» подходе. Так что, возможно, для этих конкретных случаев вы можете сделать это «по-старому».
Если вы беспокоитесь о развязке и тестировании, вы все равно можете спроектировать службы как обработчики сообщений, но использовать их напрямую, а не служебную шину.
person
MikeSW
schedule
20.01.2014
