DDD CQRS Параллельный выпуск

Question

Мы создали архитектуру на основе DDD и CQRS.Кроме того, у нас есть спокойный API с реализацией OAUTH, к которому наши клиенты могут подключатьсяНаши клиенты подключаются к нашему API и выполняют операции от имени своих клиентов.Их клиенты представлены профилями на нашей стороне.

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

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

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

Есть мысли?

Answer 1

Команды не должны возвращать результаты.

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

Но скажите, что ваш идентификатор - GUID. Затем вы можете передать GUID в команде на сервер. Бэкэнд создаст новый профиль только в том случае, если GUID еще не существует - и вы гарантируете уникальность.

Answer 2

Это правильно. Команда не должна полагаться на ReadModel из-за В конечном счете Последовательного принципа ReadModel.

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

Обычно репозитории CQRS + EventSourcing имеют очень мало методов, но одним из них является GetById (идентификатор Guid). Вы можете использовать его, чтобы проверить, присутствует ли такая сущность в домене.

Answer 3

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