Как следует выполнять поиск по критериям в Sourcing Event с CQRS

Question

Допустим, мне нужно запросить все объекты, которые соответствуют заданным критериям. Моя самая большая путаница связана с тем, откуда взять данные. Я предполагаю, что у нас есть два варианта: либо запросить само хранилище событий, либо задать какое-нибудь другое решение для хранения проекций (понятия не имею - может быть, какая-то БД или что). Это может зависеть от количества обработанных событий. Как будет выглядеть реализация?

1. , запрашивая напрямую хранилище событий, мы будем запрашивать все сущности, а затем фильтровать их в приложении?
2. , используя DB, мы просто запросим базовую таблицу, котораяпредназначен для поиска по определенным критериям

А как насчет производительности?.

В хранилище событий лучшее, что можно сделать, - это, вероятно, создать несколько снимков, но в любом случае не уверен, как составить список сложных так называемых«агрегаты». В БД у нас будет примерно такое же количество строк, что и у событий, что приведет к обширной оптимизации БД. Не говоря уже о том, что эта БД может быть удалена в любое время и заполнена снова, что я совершенно не могу себе представить. Правильно ли я все понимаю или я полностью не в курсе?

Answer 1

У вас пока нет правильного представления о CQRS. C CQRS предназначен для команд, которые только обновляют данные. Они создают объект в памяти, используя события в хранилище событий, вносят соответствующие изменения, а затем сохраняют эти изменения обратно в хранилище событий. Эта сторона не предназначена для специальных запросов. Думайте о Командной стороне как о данных, к которым вам разрешен доступ только через первичный ключ.

На стороне чтения вы можете запрашивать все объекты с определенным атрибутом. Сторона чтения встроена в БД (не хранилище событий) с помощью специального кода, который прослушивает хранилище событий и добавляет / обновляет строки в БД стороны чтения, чтобы поддерживать его актуальность. Обратите внимание, что БД на стороне чтения не является третьей нормальной формой - данные часто дублируются, и внешних ключей очень мало.

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

Пройдя по типичному примеру

1. Пользователь заходит на ваш сайт и нажимает кнопку, чтобы увидеть список синих футболок. Вы запрашиваете сторону чтения для всех сущностей Inventory с Type = "TShirt" и Color = "Blue" и возвращаете этот список на экран пользователя со счетчиком количества их на складе.
2. Пользователь нажимает нафутболка, поэтому вы запрашиваете у читающей стороны подробности о рубашке и изображении. Покажите пользователю этот экран, используя эту информацию.
3. Пользователь добавляет футболку в корзину. Вы выполняете команду AddItemToCart, которая создает событие CartCreated, затем событие ItemAddedToCart, затем событие InventoryDecremented.
4. Сторона чтения подписывается на источник события и видит эти события, поэтому она соответствующим образом обновляет свои таблицы.
5. Входит второй пользователь, который также хочет синюю футболку, но она видит, что инвентарь теперь равен 0, так как предыдущий человек получил последний. Вся эта информация поступает только из БД на стороне чтения, а не от источника событий (командная сторона).

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

Answer 2

Источник событий: - это способ разработки приложения, в котором вся информация сохраняется в виде событий. Для получения дополнительной информации см. здесь

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

• Пользователь1, транзакция: 100, ссылка: "xyz", Дата: 11 октября 2018 года
• Пользователь 1, транзакция: -100, ссылка: "xyza", Дата: 18 октября 2018
• ии так далее ...

Теперь, если Пользователь1 хочет дебетовать его / ее счет, мы извлекаем все события из его / ее потока и воспроизводим, чтобы получить баланс. И если он / она имеет достаточный баланс, то мы дебетуем его / ее счет, добавив одно дебетовое событие.

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

Трудности в системе источников событий связаны с запросами. Если нам нужно получить список пользователей, которые внесли более 10000 единиц в квартал, то это будет сложно и отнимает много времени, так как нам нужно воспроизвести поток каждого пользователя. Чтобы решить эту проблему, мы можем использовать CQRS.

CQRS: - это схема разработки программного обеспечения, в которой запись выполняется одним приложением, а чтение - другим приложением. Более подробная информация доступна здесь . Приложение записи и приложение чтения могут связываться друг с другом (может быть посредством обмена сообщениями). Приложение read может поддерживать собственную базу данных и хранить информацию в удобной для запроса форме. Поэтому, когда приложение read получает сообщение, оно преобразует сообщение, которое подходит для его собственной схемы БД, и сохраняет его.

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

Теперь отвечаю на ваш вопрос:

• Существуетнемного времени, затраченного на обновление данных в приложении записи. Приложение записи воспроизводит все события (или события после моментального снимка) перед любым обновлением. Пока агрегаты невелики, и мы используем правильные методы моментальных снимков, производительность неплохая.
• Модель чтения имеет свою собственную базу данных, схема разработана для удовлетворения запросов. Много раз мы не беспокоимся о избыточных данных в базе данных для чтения. Это сделано для быстрого выполнения запросов.
• Мы могли бы принять решение выбросить данные приложений (моделей) для чтения и перестроить их в другую форму для соответствия новым запросам, поскольку источником правды являются события, хранящиеся в приложении записи (модель).