Возможная последовательность при регистрации пользователя

Question

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

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

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

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

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

Я хотел бы услышать обратную связь, какой случай имеет больше смысла, и есть ли какие-либо проблемы, которые я не вижу на этом этапе?

Answer 1

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

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

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

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

Answer 2

Если молоток - это то, что у вас есть, все выглядит как гвоздь. Похоже, вы слишком стараетесь применять грандиозные идеи к проблеме, которая не гарантирует этого.

При приближении к задачам с использованием DDD жизненно важно придать стратегическому DDD мысли, т. Е. Конструктивную часть. Ограниченный контекст - это место, где существует конкретный язык и проявляется как реализация, связанная с конкретными бизнес-возможностями.

Теперь ваша работа - смотреть на каждый БК, чтобы судить о том, какая архитектура подходит для этого контекста. Вся система не должна, я должен сказать, не должна, должна следовать той же самой реализации. Вам действительно нужны микросервисы для создания учетной записи \ входа в систему? Похоже, вы можете уйти с реализацией, подобной CRUD, устраняя любые возможные проблемы согласованности, которые вы ввели.

Держите его простым, сэр.