Информация о полезной нагрузке событий домена / интеграции в архитектуре DDD CQRS - PullRequest
Новая
       36

Информация о полезной нагрузке событий домена / интеграции в архитектуре DDD CQRS

0 голосов
/ 04 июля 2019

У меня есть вопрос о событиях интеграции, используемых в архитектуре микросервиса / CQRS.

Полезная нагрузка события может иметь только ссылки на агрегаты или может содержать больше информации?

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

отл.когда пользователь создан и событие поднято.

UserCreated {
   userId
   name
   lastname
   document
   ...
}

Это правильно?

1 Ответ

1 голос
/ 05 июля 2019

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

Почему разрешено только это? Я работал с системой, которая использовала микросервисы, CQRS и DDD (похожие на вашу), и у нас не было таких ограничений. Как и в большинстве случаев это: «Что лучше всего подходит для вашего приложения / бизнес-домена». Не следуйте никаким правилам вслепую. Это прекрасно для того, чтобы поместить другую информацию в полезную нагрузку событий.

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

Это также хорошо в некоторых случаях, но это приводит вас к ситуации, когда после обработки события вы получаете дополнительный вызов. Я бы не стал этого делать, если у вас нет действительно тяжелой модели / моделей, и это повлияет на вашу производительность. Например, если у вас есть событие, выполненное и основанное на userId, вам по какой-то причине необходимо загрузить коллекцию связанных объектов / моделей. У меня был один подобный случай, когда мне приходилось загружать коллекцию других объектов на основе какого-либо действия над пользователем, например, события UserCreated. Конечно, в этом случае вы не хотите отправлять все эти данные в одном информационном наполнении события. Вместо этого вы отправляете только идентификатор пользователя, а затем вызываете Get API из другого сервиса, чтобы получить и сохранить эти данные в своем микросервисе.

UserCreated {
* идентификатор пользователя 1015 * Имя
фамилия
документ
...}

Это правильно?

Да, это нормально :) 1024 *

Что вы могли бы сделать вместо:

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

    1. событие: UserCreatedDraft с некоторыми начальными данными со страницы 1-го мастера
    1. событие: UserPersonalDataCreated только с частью объекта, связанной с личными данными
    1. событие: UserPaymentDataСоздано только с созданными данными платежа
    1. UserCreatedFinal с последним шагом

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

Резюме:

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

...