Добавление данных из пользовательского интерфейса в разные микросервисы

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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