Лучшие практики для взаимодействия микро-услуг с Event-Sourcing (CQRS)

Question

У меня есть вызов API, который должен работать с несколькими агрегатами. У меня в голове есть 2 идеи о том, как они должны взаимодействовать с агрегатами, но я открыт для других идей.

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

Answer 1

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

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

Это означает, что нам необходимо поддерживать асинхронный обмен сообщениями от A до B.

Текущий "лучший метод«если вы имеете дело с сообщениями, доставляемыми асинхронно, то семантика должна быть в прошедшем времени: SomethingHappened в A, и B будет реагировать на нее или нет, в свое время по своему усмотрению.

Имеет ли это значение?Трудно сказать - handle(Event) - это команда , CommandReceived - это событие .

Примечание: на самом деле это просто службы и обмен сообщениями - Event-Sourcing / CQRS действительно не входит в него.

Мартин Фаулер описал доменные события в 2005 году.

Каждое доменное событие собирает информацию от внешнего стимула.

Если вы думаете о A как о external to B (что имеет смысл, если между ними есть границы служб), то семантика события доменашаблон может быть очень хорошо подходит.

Answer 2

Почему не оба?

Я подхожу к этим "микро-услугам" немного по-другому.У меня обычно есть конечная точка обмена сообщениями для каждого ограниченного контекста.Я предполагаю, что это хорошо согласуется с идеей микро-сервиса и , что конечная точка отвечает только на команды, отправленные ей, которые применяются к этому BC.Затем он также опубликует соответствующие события.

То, что я затем также могу иметь , это конечная точка оркестровки , которая отвечает менеджерам процессов, которые "принадлежат" к соответствующему BC,Эта конечная точка имеет дело только с состоянием менеджеров процессов и выдает команды для каждой конечной точки обмена сообщениями BC, с которой ей необходимо связаться.Например, после получения OrderRegisteredEvent может быть выдано SendEMailCommand.Хорошо, это скорее техническая конечная точка / BC, но тем не менее.

На конечной точке обмена сообщениями только для BC есть абсолютно нет между различнымиBCS. только там, чтобы обслуживать собственную БК.

Надеюсь, это имеет смысл.