БД хранилища событий: временные запросы

относительно заданного вопроса здесь:

предположим, что у нас есть события ProductCreated и ProductRenamed, которые оба содержат название продукта. Теперь мы хотим запросить EventStoreDB для всех событий типа ProductCreated и ProductRenamed с заданным заголовком. Я хочу, чтобы все эти события проверяли, есть ли какой-либо продукт в списке. система, которая была создана или переименована в данный заголовок, чтобы я мог исключить повторяющийся заголовок в домене

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

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

нет, странно то, что проекции отлично подходят для подписки и создания новых потоков, но они кажутся странными для выполнения запросов в реальном времени. Сразу после создания проекции с помощью HTTP API я проверяю новый результирующий поток на предмет результата запроса, но похоже, что у рабочих не было возможности уточнить результат, и я получаю ответ 404. Но после ожидания нескольких секунд новые потоки выскакивают и заполняются результатом.

в этом подходе слишком много неправильного:

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

во-вторых, мне приходится получать несколько раз и выполнять несколько команд GET HTTP, которые кажутся медленными. Новый клиент JVM еще не готов.

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

Я хотел бы передать java-скрипт какому-нибудь API и получить результат страница за страницей, например, запрашивая MongoDB, не беспокоясь о проекции, новых потоках и проблемах синхронизации.

я видел раздел запроса в пользовательском интерфейсе администратора, но я не знаю, для чего он нужен, и, к сожалению, документация не очень помогает

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

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


eventstoredb
person Masoudy BaBa    schedule 08.09.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

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

Практически, когда у вас есть такая проекция, все, что требуется, — это построить простую доменную службу bool ProductTitleAlreadyExists.

person Alexey Zimarev    schedule 08.09.2020
comment
проверка продукта с уникальным заголовком была примером, показывающим, можем ли мы запросить базу данных хранилища событий. И с вашим описанием я пришел к выводу, что невозможно запросить базу данных хранилища событий, как мы знаем и опыт запросов от других .and проекции не эквивалентны запросу, по крайней мере, не в том, как они доставляют результат. есть волшебные простые запросы, которые создаются с проверкой простых критериев по некоторым событиям и понимают, что я должен использовать другую модель записи внутри моего BC, чтобы сделать что я хотел бы запросить базу данных хранилища событий так же, как я запрашиваю MongoDB. Спасибо в любом случае - person Masoudy BaBa; 08.09.2020
comment
Что ж, давайте внесем ясность. Если мы говорим о временных запросах, то должна быть задействована концепция времени. Как это произошло, а через 5 минут произошло что-то еще. Когда дело доходит до запросов, я считаю важным понимать, что запрос событий сильно отличается от запроса состояния. Хотя вы можете написать специальную проекцию для запроса, это не основной вариант использования, который вы будете использовать в своих приложениях. eventstore.com/blog/projections-4-event-matching - person Alexey Zimarev; 09.09.2020