Какова взаимосвязь между 1) событиями домена и согласованностью транзакций и 2) событиями интеграции и окончательной согласованностью

Question

Я понимаю разницу между транзакционной последовательностью и возможной последовательностью.Скажем, я разрабатываю приложение, в котором есть три микросервиса и существует шина сообщений, которая отправляет сообщения между ними при возникновении событий интеграции, что означает конечную согласованность.Например, Microservice B публикует событие интеграции, а Microservice A обрабатывает его два часа спустя, потому что Microservice B был недоступен во время публикации события, и сообщение является надежным - это нормально.

Как я понимаю;внутри микросервиса должна быть согласованность транзакций - Агрегат A может публиковать событие домена, в котором заинтересован Агрегат B, поэтому возникает Событие домена, и любые обновления базы данных выполняются в рамках одной транзакции.

Я не делаюпонять, как CQRS вписывается в этот сценарий согласованности транзакций / возможной согласованности, потому что:

1. Я не могу использовать согласованность транзакций, поскольку модель чтения (NoSQL) и модель записи (сервер SQL) не могут быть обновлены внутри одной транзакции.
2. Я не могу использовать шину сообщений, потому что обновление модели чтения не является событием интеграции, т. Е. Модель чтения и модель записи содержатся внутри одного и того же микросервиса.

В CQRS я полагаю, чтоЕсть два варианта:

1. Если использовать хранилище событий для стороны записи, то сторона чтения может опрашивать ее - это решает проблему, потому что нет события.
2. При использовании журнала событий / реляционной базы данных для стороны записи генерируется событие домена для обновления стороны чтения.

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

Answer 1

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

AGGREGATE - это кластер связанных объектов, которые мы рассматриваем как единое целое для целей изменения данных ... Инварианты, которые представляют собой правила согласованности, которые должны поддерживаться при изменении данных,будет включать отношения между членами AGGREGATE.Предполагается, что любое правило, охватывающее AGGREGATES, не будет постоянно обновляться ... Но инварианты, применяемые в AGGREGATE, будут применяться с завершением каждой транзакции.

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

В настоящее время я использую библиотеку MediatR для отделения доменаобработчики событий из исходного обработчика команды / запроса, который их генерирует.Он очень похож на семантику отправки / обработки с системами обмена сообщениями и включает в себя надежный промежуточный конвейер для проверки и предварительной / последующей обработки.

Answer 2

Если выбран второй вариант, то как я могу гарантировать, что модель чтения будет синхронизирована с моделью записи?

Решение представляет собой сочетание двух ваших вариантов:

• Вызывает событие домена при выполнении команды.

• Сохранение события домена в хранилище событий в модели записи.Эта задача выполняется легким статическим подписчиком.Событие сохраняется в той же транзакции, в которой выполняется команда.

• Рабочий или пакетный процесс принимает события из хранилища событий и отправляет их через очередь сообщений.

• Подписчик забирает их из очереди и обновляет модель чтения.

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

Answer 3

CQRS вписывается в концепцию возможной согласованности, обеспечивая более низкую уязвимость против оптимистических блокировок при использовании систем СУБД для систем, доступных только для чтения.Разделение ваших команд и запросов позволяет вам иметь работающее чтение / запись независимо от того, доступны ли они.

1).Согласованность транзакций не рекомендуется, если вы хотите иметь высокодоступные конечные точки из-за оптимистической блокировки.

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