CagRS sagas - я правильно их понял?

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

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

В принципе, сага - это не что иное, как обработчик команд/событий, который реагирует на внутренние и внешние команды/события. Он не содержит своей собственной логики, это просто конечный конечный автомат и поэтому предоставляет такие задачи, как Когда происходит событие X, отправьте команду Y.

Саги сохраняются в хранилище событий, а также в агрегатах, коррелируются с конкретным агрегатным экземпляром и, следовательно, перезагружаются, когда используется этот конкретный агрегат (или набор агрегатов).

Правильно ли это?

Ответ 1

Существуют различные способы реализации Саги. Достижение из обработчиков событий без состояния, которые публикуют команды вплоть до переноса всего состояния и в основном являются агрегатами домена. Уди Дахан однажды написал статью о том, что Сагас является единственным Агрегатом в (в его конкретном случае) правильно смоделированной системе. Я просмотрю его и обновлю ответ.

Также существует концепция саги, основанных на документах.

Ответ 2

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

Единственное изменение в вашем описании, которое я сделал бы, это то, что сага - это только обработчик событий (а не команда) для событий (событий) и на основе принимающего события, а его внутреннее состояние создает команду и передает ее в CommandBus для выполнение.

Обычно у Саги есть только одно событие, которое должно быть запущено (StartByEvent) и несколько событий для перехода (TransitionByEvent) в следующее состояние, и мутированное событие, которое должно быть завершено (EndByEvent).

В MSDN они определили Sagas как ProcessManager.

Ответ 3

Термин сага обычно используется в обсуждениях CQRS для обозначения фрагмент кода, который координирует и направляет сообщения между ограниченным контекстов и агрегатов. Однако для целей настоящего руководства мы предпочитают использовать термин диспетчер процессов для обозначения этого типа кода артефакт. Для этого есть две причины: существует известная, уже существующее определение термина сага, имеющее другое значение от общепринятого в отношении CQRS. Срок диспетчер процессов - лучшее описание роли, выполняемой этим тип артефакта кода. Хотя термин сага часто используется в контекст шаблона CQRS, он имеет уже существующее определение. У нас есть чтобы использовать термин "менеджер процессов" в этом руководстве, чтобы избежать путаница с этим ранее существовавшим определением. Термин сага в отношение к распределенным системам, изначально было определено в документе "Саги" Гектора Гарсия-Молина и Кеннета Салема. В этом документе предлагается механизм, который он называет сагой как альтернативу использованию распределенной транзакции для управления долгосрочным бизнес-процессом. В документе признается, что бизнес-процессы часто состоят из несколько шагов, каждая из которых связана с транзакцией, и что в целом согласованность может быть достигнута путем группировки этих отдельных транзакций в распределенную транзакцию. Однако в долгосрочном бизнесе процессы с использованием распределенных транзакций могут производительность и concurrency системы из-за блокировок, которые должны храниться на протяжении всей распределенной транзакции.

ссылка: http://msdn.microsoft.com/en-us/library/jj591569.aspx