Почему CQRS, кажется, предотвращает уникальные ограничения на стороне записи?
Это не
Что он делает, так это признает, что поддержание инварианта в распределенном наборе является кошмаром.
самое очевидное для меня решение, которое заключается в добавлении уникального индекса на стороне записи, никогда не упоминается, без объяснения причин
Это верно. Если у вас нет распределенного набора - если все элементы набора хранятся вместе - тогда сохранение инварианта не вызывает затруднений.
Но что значит иметь уникальное ограничение индекса, охватывающее две базы данных?
Чтобы выразить идею в более современных терминах, руководящим предположением является то, что бизнес-логика должна быть независимой от масштаба . Если две модели записи действительно независимы друг от друга, то мы должны иметь возможность хранить их отдельно.
Если существует ограничение, которое должно быть удовлетворено и зависит от данных двух разных моделей записи, то эти модели записи на самом деле не являются независимыми.
Грег Янг поднял действительно хороший вопрос
Какое влияние имеет неудача на бизнес?
В конце концов, именно об этом мы должны думать при проектировании, управляемом доменом.
Почему источник событий не позволяет мне указывать уникальные поля?
Тот же самый ответ: это не так, , пока ваше уникальное ограничение и ваши события хранятся вместе .
Если у вас есть RDMBS с таблицей, представляющей элементы вашего набора, и таблицами, в которых хранятся ваши события, вы можете обновить две таблицы вместе в рамках одной транзакции и откатить весь беспорядок, если ваше ограничение нарушено.
Но возьмите ту же идею и поместите набор в другую базу данных, чем события? Теперь у вас есть две разные транзакции для координации. Удачи с этим.