Как я могу атомарно (или, по крайней мере, правильно) создать пользователя в системе с несколькими ограниченными контекстами?
Мне нужно зарегистрировать пользователя в системе. Пользователь не может существовать без роли (и он, конечно, не может существовать без логина и пароля). Предполагается, что администратор сможет добавлять новых пользователей, выбирая роль, вводя логин / пароль и некоторую информацию о пользователе. Проблемы с логином / паролем / безопасностью реализованы в виде отдельного приложения /BC (контекст аутентификации), роли и разрешения находятся в контексте авторизации, а информация о пользователе - в отдельном контексте управления учетной записью. Как я могу реализовать процесс регистрации пользователей, если теоретически все эти контексты могут быть развернуты на отдельных машинах? На данный момент я использую интерфейс приложения, который использует реализацию службы инфраструктуры для синхронной и атомарной отправки всех необходимых команд различным BC (в настоящее время это одно и то же большое приложение).
3 ответа
Возможно, вы достигли слишком тонкой степени детализации в своих ограниченных контекстах. Об этом свидетельствует обычно, когда концепция, на которую вы ссылаетесь, является одной и той же вещью в более чем одном ограниченном контексте.
Вещи как User управление (регистрация / аутентификация / авторизация) обычно обрабатывается ограниченным контекстом идентификации и контроля доступа.
Тот User будет иметь различные значения / концепции в ваших нижестоящих ограниченных контекстах: например, Автор, Супервизор и т. д.
Однако, если вы уверены, что хотите получить такой уровень детализации, вам нужно будет выбрать систему записей для вашего пользователя, и этот ограниченный контекст будет принадлежать пользователю и отвечать за состояние диспетчера процессов и следить за регистрацией до завершение; хотя я обычно хотел бы, чтобы управление процессами само по себе было ограниченным контекстом, и оно может быть организовано среди других.
Что касается атомарного подхода... Я не знаю, стоит ли пытаться делать это:)
Простой архитектурный ответ: используйте Saga (или Process Manager) который организует все это.
У вас есть архитектура, которая состоит из трех микросервисов. Существует два способа интеграции микросервисов: оркестровка и хореография. Saga использует оркестровку.
Читайте больше на SO о различиях между ними.
Обновление: я думаю, что Account management должен быть хозяином до н.э. Здесь рождается пользователь, изначально без роли или смысла для аутентификации. Затем ему присваивается роль, цель и после этого, после настройки, имя пользователя и пароль. Это должно быть последовательность.
Для этого вам понадобится сервер распределенных транзакций. У Java есть стандарт для распределенных транзакций (JTA).