CQRS 1st NF Read Model - до какой степени вы допускаете дублирование?

Question

Я начинаю с моей первой реальной установки CQRS.Я строю часть сайта, посвященную регистрации пользователей, домен и сторона записи мне очень знакомы, исходя из стандартного «стиля» DDD.Для модели чтения у меня есть денормализатор, который обрабатывает AccountCreatedEvent.

На данный момент - для функции, которую я реализую, меня интересует только регистрация пользователей.Это включает проверку уникальности адреса электронной почты / имени пользователя.

Итак, скажем, я разработал модель чтения специально для этой цели.AccountRegistrationReadModel, которая содержит только те части данных, которые меня интересуют прямо сейчас: имя пользователя, электронная почта, HashedPassword

Позже, когда я начну создавать страницу профиля пользователя, мне понадобитсяAccountProfileReadModel.

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

На этом этапе AccountRegistrationReadModel и AccountProfileReadModelзаинтересованы в прослушивании сообщений AccountUsernameChangedEvent.

Мой вопрос: правильный ли это подход?Должен ли я хранить модель чтения для каждой функции?Или я должен попытаться нормализовать его и повторно использовать данные, по возможности ограничить дублирование?

Answer 1

Я думаю, что, как и большинство вопросов о дизайне, ответ на этот вопрос зависит от вас.Совместное использование сэкономит вычислительные ресурсы и ограничит количество мест, которые вы должны отлаживать с течением времени.Но совместное использование также будет связывать вещи вместе, потенциально излишне, что приведет к другому типу затрат: хрупкость.В системе с несколькими тысячами пользователей и скучными запросами простая и классическая таблица пользователей в базе данных может подойти для большинства ваших моделей чтения.Если вам нужно масштабировать до огромного количества пользователей или огромного количества сообщений, вы, вероятно, обнаружите, что некоторые другие ваши представления (журнал аудита? В настоящее время активные поставки? И т. Д.) Будут включать более интересную денормализацию или реализацию.

Answer 2

Я согласен с тем, что @Sebastian сказал в своем ответе. Я бы также добавил, что, по моему мнению, паттерн CQRS дает вам возможность быстрого чтения за счет немного более медленного процесса модификации (из-за нормализации). Ваши чтения идут против довольно плоских данных; в результате у вас есть некоторое дублирование в вашем хранилище данных. Но ваши денормализаторы поддерживают это обновление.

Итак, как сказал @Sebastian, решать вам. Но главное преимущество перехода на CQRS - быстрое чтение и масштабируемость. Если вы начнете нормализовать свои данные и обмениваться данными между моделями, то вы вернетесь к более традиционному приложению CRUD. В этот момент CQRS на самом деле вам не помогает - поэтому, возможно, нет смысла использовать его.

Надеюсь, это поможет. Удачи!