Да, возникает путаница. Вот как это происходит: во-первых, для того, чтобы действительно помочь новым людям понять, что такое CQRS, и действительно показать, чем он отличается от типичной многоуровневой архитектуры, люди говорят что-то вроде: «Ваши модели представлений могут быть абсолютно плоскими», и «В вашей базе данных запросов должна быть одна таблица для каждой модели представления».
Но это на самом деле просто для того, чтобы уяснить ситуацию ... неправда, что у вас должна быть только одна таблица на модель представления (хотя в большинстве случаев вам, вероятно, следует). Эти заявления пытаются сказать так: «Вы должны избавиться от некоторых правил, которых вы так долго придерживались в вопросе нормализации. С архитектурой CQRS у вас есть возможность создавать таблицы базы данных в своем канале запросов которые полностью сформированы в соответствии с потребностями вашего взгляда и ничем иным. Убедитесь, что вы в полной мере используете это. Не идите на полпути, нормализуя эти таблицы только потому, что это то, что вы привыкли делать. Вместо этого, идти вперед и делать вещи, которые раньше считались немыслимыми, такие как создание одной таблицы базы данных на модель представления или создание полностью плоских таблиц модели представления. "
Есть еще такие случаи, как у вас, когда схема, которая лучше всего соответствует вашим потребностям, будет иметь несколько таблиц. Вы можете даже (не дай Бог) сделать соединение или два Это нормально, если вы действительно спроектировали таблицы базы данных для обслуживания вашего представления, а не наоборот. Но будьте осторожны, легко сползти вниз по пути нормализации и обмена данными между многими представлениями в базе данных запросов. Не ходите туда ... просто нет причин, и это приносит больше затрат, чем выгод. Основная цель заключается в следующем: логика вашего представления должна быть мертвой, очень простой. Вы хотите, чтобы интеллектуальные правила жили в командной части дома и немного в подписчиках, которые заполняют данные в канале запросов. Поэтому код, который читает из базы данных запросов и показывает данные на экране, должен быть очень простым (почти таким же простым, как «пассивное представление»).
Обновление: В качестве еще одного подтверждения заявления о том, что некоторые объединения не "запрещены", если вы разработали форму базы данных для наилучшего выполнения задачи, которую вы достигаете, рассмотрите OLAP. Схема типа "звезда" является совершенным примером схемы базы данных, разработанной для поддержки reads , которая идеально вписывается в сторону запроса CQRS, и что делает включает в себя соединения. Объединения остаются простыми и используются для дальнейшего улучшения целей задач чтения, выполняемых для базы данных.