Трудность Понимание Источника Событий Микросервис Прием Событий / Связь

Question

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

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

Трудность, с которой я сталкиваюсь, - это связь и обработка событий из службы -to-service (как из службы записи в чтение, так и между микро-службами).

Поэтому я хочу сосредоточиться на хранилище событий (это: https://eventstore.com/, чтобы быть менее двусмысленным). Это то, что я хочу использовать, так как я понимаю, что оно идеально подходит для получения событий, а простая природа хранения событий означает, что я могу использовать это и для шины сообщений.

Таким образом, моя проблема состоит из двух вопросов :

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

2. Между микро-службами у меня даже труднее ... Так что, глядя на учебники / доклады по CQRS и т. д. c ... они, кажется, всегда говорят с примером изолированного сервиса, который получает команды от UI / API. Это хорошо. Я понимаю, что к стороне записи будет прикреплен API, чтобы пользователь мог взаимодействовать с ним для выполнения команд. Например, создать клиента. Однако ... скажите, если у меня есть две микро-службы, например, микро-служба заказа и микро-служба доставки, как микро-служба доставки получает события, публикуемые из микро-службы заказа. В частности, как эти события клиентов переводятся в команды для службы доставки.

Итак, давайте рассмотрим простой пример: - Команда, созданная из API заказа для размещения заказа. - OrderPlacedEvent публикуется в хранилище событий. Как служба доставки прислушивается к этому и реагирует на это, нужно ли тогда DispatchOrder и создавать, в свою очередь, OrderDispatchedEvent.

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

Answer 1

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

Трудность Вы не виноваты - литература DDD очень слаба, когда речь заходит об обсуждении сантехники.

Грег Янг обсуждает некоторые вопросы подписки в последней части своих Полигот Данных talk.

Eventide Project имеет документацию, которая делает хорошую работу по объяснению принципов, лежащих в основе сантехники.

Между микро сервисами я с еще более трудным временем ...

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

Таким образом, хост извлекает из хранилища документ с событиями в нем и преобразует этот документ в поток handle(Event) команд, которые в конечном итоге передаются компоненту вашего домена.

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