Почему команды и события представлены отдельно?

Ответ 1

Команды могут быть отклонены.

События произошли.

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

Теперь, потому что Команды - это то, что мы хотим, и События - это то, что произошло, мы должны использовать разные глаголы, когда будем называть эти вещи. Это приводит к отдельным представлениям.

Я вижу, что команды обычно источники/привлеченные субъектами вне системы, тогда как события, похоже, полученных обработчиками и другим кодом в система

Это еще одна причина, по которой они представлены отдельно. Концептуальная ясность.

Команды и события - это и сообщения. Но они на самом деле являются отдельными понятиями, а концепции должны быть явно моделированы.

Ответ 2

Проработав несколько примеров и особенно презентацию Грега Янга (http://www.youtube.com/watch?v=JHGkaShoyNs), я пришел к выводу, что команды являются излишними. Это просто события от вашего пользователя, они нажали эту кнопку. Вы должны хранить их точно так же, как и другие события, потому что это данные, и вы не знаете, хотите ли вы использовать его в будущем представлении. Ваш пользователь добавил, а затем удалил этот элемент из корзины или, по крайней мере, попытался. Позднее вы захотите использовать эту информацию, чтобы напомнить пользователю об этом позже.

Ответ 3

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

Скажите, например, что после создания Клиента вы также хотите инициализировать некоторые значения учетных записей и т.д. После того, как ваш клиент AR добавит событие в EventDispatcher, и это будет получено объектом CustomerCreatedEventHandler, этот обработчик может инициировать отправку команда, которая будет выполнять все, что вам нужно, и т.д.

Кроме того, существуют DomainEvents и ApplicationEvents. Разница просто концептуальна. Вы хотите сначала отправить все события своего домена (некоторые из них могут создавать события приложений). Что я подразумеваю под этим?

Инициализация учетной записи после возникновения события CustomerCreatedEvent является событием DOMAIN. Отправка уведомления электронной почты Клиенту - это событие приложения.

Причина, по которой вы не должны смешивать их, понятна. Если ваш SMTP-сервер временно отключен, это не означает, что на это влияет DOMAIN OPERATION. Вы по-прежнему хотите сохранить неповрежденное состояние своих агрегатов.

Обычно я добавляю события моему диспетчеру на уровне совокупного корня. Это события DomainEvents или ApplicationEvents. Может быть и то и другое, и многие из них. Как только мой обработчик команд будет завершен, и я вернусь в стек к коду, который выполняет обработчик Command, тогда я проверяю свой Диспетчер и отправляю любой другой DomainEvent. Если все это будет успешным, я закрою транзакцию.

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

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

Тогда у вас есть Саги.... но это WAYYYY OFF из сферы этого вопроса:)

Имеет ли смысл?

Ответ 4

Они представлены separetly, потому что они представляют собой очень разные вещи. Поскольку @qstarin говорит, что команды - это сообщения, которые могут быть отклонены, и что при успешном вызове будет происходить событие. Команды и события - это Dtos, они - сообщения, и они имеют тенденцию выглядеть очень похожими при создании и сущности, однако с тех пор не обязательно.

Если вас беспокоит повторное использование, вы можете использовать команды и события в качестве конвертов для вашей полезной нагрузки (messge)

class CreateSomethingCommand
{
    public int CommandId {get; set;}

    public SomethingEnvelope {get; set;}
 }

однако, что я хотел бы знать, почему вы спрашиваете: D т.е. у вас слишком много команд/событий?

Ответ 5

В дополнение к концептуальным различиям, упомянутым выше, я думаю, что существует другая разница, связанная с общими реализациями:

События обычно обрабатываются в фоновом цикле, который должен опросить очереди событий. Любая сторона, заинтересованная в действии на мероприятие, может, как правило, регистрировать обратный вызов, который вызывается в результате обработки очереди событий. Таким образом, событие может быть одним для многих.

Команды, возможно, не должны обрабатываться таким образом. Создатель команды, как правило, имеет доступ к предполагаемому исполнителю команды. Это может быть, например, в виде очереди сообщений для исполнителя. Таким образом, команда предназначена для одного объекта.

Ответ 6

Я думаю, что добавить к quentin-santin ответ, что они:

Инкапсулировать запрос как объект, тем самым позволяя параметризовать клиентов с различными запросами, запросами очереди или журналов и поддержкой отменяемые операции.

Источник.