Представьте, что у вас есть форма регистрации пользователя, где вы заполняете форму: Имя, Фамилия, Возраст, Адрес, Предпочтительный способ связи: SMS, электронная почта (радиокнопки).
У вас есть 2 микросервиса:

  • Сервис UserManagement
  • Служба связи

Когда пользователь зарегистрирован, мы должны создать 2 агрегата в 2 сервисах: User в UserManagementContext и UserCommunicationSettings в коммуникации.
Есть три способа достижения этой цели:

  1. Выполните 2 разных запроса из пользовательского интерфейса. Что если один из них потерпит неудачу?
  2. Поместите все эти данные в User, а затем создайте событие интеграции со всеми этими данными, перехватите их в CommunicationContext. Жирные события, события интеграции не должны содержать доменные данные, только идентификаторы аггрегатов.
  3. Поместите сообщение в очередь, чтобы оба контекста имели адаптеры для получения необходимой информации.

Каков наилучший вариант для разделения этих данных и сохранения информации?

0
DmitriBodiu 21 Фев 2019 в 13:17

2 ответа

Лучший ответ

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

Я вижу пару проблем с подходом № 3, предложенным в другом ответе. Хотя я думаю, что подход № 3 в оригинальном ответе очень похож на мой ответ.

  • Что если добавить больше режимов связи? Естественно, это должно привести только к изменению службы связи, а не службы управления пользователями. SRP. Настройки связи MS должна хранить все данные, связанные с настройками связи, в своем собственном хранилище данных.

  • Что если пользователь обновит только свои настройки связи? Почему служба управления пользователями должна нести бремя обработки этого? Изменение настроек связи должно привести к изменениям в соответствующем микросервисе, в нашем случае - «Услуга связи».

  • Я просто считаю, что для идентификации и сопоставления сущностей в микросервисах лучше использовать естественные ключи, а не внутренние идентификаторы, генерируемые БД. Учтите, что завтра вы решите использовать совершенно другую стратегию для создания «идентификаторов» пользователей для службы UserManagement, например. нечисловые идентификаторы, другой алгоритм генерации идентификаторов и т. д. Я бы хотел, чтобы другие микросервисы не зависели от любых таких решений.

Предлагаемый подход:

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

API Gateway in microservices architecture to perform writes

1
Vishal Shukla 25 Фев 2019 в 10:25

Выполните 2 разных запроса из пользовательского интерфейса. Что если один из них потерпит неудачу?

Я не думаю, что это подойдет. Вы окажетесь в противоречивом состоянии.

Я за подход 3 #:

  1. Пользователь сохраняется (создается) в вашем пользовательском магазине.
  2. Событие UserRegistered отправляется с идентификатором пользователя.
  3. Все заинтересованные стороны обрабатывают событие UserRegistered.

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

3
Alex Buyny 21 Фев 2019 в 19:24