Источник событий CQRS: проверка уникальности имени пользователя

Возьмем простой пример «Регистрация учетной записи», вот процесс:

• Пользователь посещает веб-сайт
• Нажмите кнопку «Регистрация» и заполните форму, нажмите «Сохранить» button
• Контроллер MVC: Проверить уникальность имени пользователя, прочитав из ReadModel
• RegisterCommand: Проверить уникальность имени пользователя еще раз (вот вопрос)

Конечно, мы можем проверить уникальность имени пользователя, прочитав из ReadModel в контроллере MVC, чтобы повысить производительность и пользовательский опыт. Однако нам все еще нужно снова проверять уникальность в RegisterCommand, и, очевидно, нам НЕ следует обращаться к ReadModel в Commands.

Если мы не используем Event Sourcing, мы можем запросить модель предметной области, так что это не проблема. Но если мы используем Event Sourcing, мы не можем запрашивать модель предметной области, поэтому как мы можем проверить уникальность имени пользователя в RegisterCommand?

Примечание: класс пользователя имеет свойство Id, а имя ключевое свойство класса User. Мы можем получить объект домена только по идентификатору при использовании источника событий.

Кстати: В требовании, если введенное имя пользователя уже занято, веб-сайт должен показать посетителю сообщение об ошибке «Извините, имя пользователя XXX недоступно».Недопустимо показывать посетителю сообщение, например, «Мы создаем вашу учетную запись, пожалуйста, подождите, мы отправим вам результат регистрации по электронной почте позже».

Есть идеи? Большое спасибо!

[UPDATE]

Более сложный пример:

Требование:

При оформлении заказа система должна проверять историю заказов клиента, является ли он ценным клиентом (если клиент разместил не менее 10 заказов в месяц за последний год, он ценный), делаем скидку 10% на заказ.

Реализация:

Мы создаем PlaceOrderCommand, и в этой команде нам нужно запросить историю заказов, чтобы узнать, является ли клиент ценным. Но как мы можем это сделать? Мы не должны обращаться к ReadModel в команде! Как сказал Микаэль , мы можем использовать компенсирующие команды в примере с регистрацией учетной записи, но если мы также используем это в этом примере с заказом, это будет слишком сложно, а код может быть слишком сложным для сопровождения.