CQRS design: nosql data view

Это вопрос «языковой агностик». Я начал изучать шаблон CQRS.CQRS design: nosql data view

У меня вопрос простой. Я предполагаю, что у меня есть два разных уровня хранения: одна реляционная для команд (Mysql и т. Д.) И одна NoSql (mongo, cassandra .. и т. Д.) Для «запроса»?

Позвольте мне объяснить немного пример:

1) Как пользователь, я хочу, чтобы вставить «Todo задачу» Команда: «Создать задачу» и вставить новую задачу в базу данных, которые имеют пользователя и таблицы Todo.

2) Как пользователь, я могу видеть список созданной задачи Запрос: «GetTasks», который вернет «представление» с коллекцией задач, взятой из таблицы без sql с именем «UserTasks», которые имеют пользователя и списка созданной задачи.

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

Я собираюсь поднять событие типа «TaskCreated» и выполнить новую задачу и вставить эту информацию в хранилище nosql.

Спасибо!

источник

2014-12-05 erlangb

CQRS не требует различных моделей сохраняемости, просто разные модели приложений (Domain и запросов).В зависимости от вашего приложения вы можете использовать одну и ту же модель сохранения для обеих потребностей, или вам понадобятся конкретные модели устойчивости для каждого. Дело в том, что это не _must_, вам решать, лучше ли 1 или 2 модели для вашего приложения. – MikeSW

Хорошо спасибо за ответ Майк. Да, как обсуждалось выше, я знаю, что вы можете выбрать разные решения в каждом конкретном случае. Я просто любопытство, если в некоторых случаях это не нарушение «cqrs design», использующее два разных хранилища данных: один для команды и один для запроса. Если нет, то в этом случае лучший способ сохранить хранилище данных запроса обновления с помощью «команды»? – erlangb

CQRS = 1 Модель домена и по меньшей мере одна модель чтения. Вот и все. Все остальное - подробности реализации. CQRS - это просто принцип, вы решаете, как он будет реализован. – MikeSW

Я не могу понять, что вы ищете. но ... как правило, команда будет чем-то, что приводит к побочным эффектам. Запросы не вызывают побочных эффектов. GetTasks не будет действительно командой, а запросом.

Ваша «CreateTask» будет командой, которая приведет к добавлению задачи в соответствующие хранилища данных. Ваш запрос GetTasks будет извлекать эту информацию из хранилища данных. На самом деле не имеет значения, используете ли вы для этого хранилище SQL или NoSQL.

«CommandStore» - это, как правило, хранилище, в котором имеется достаточно данных для принудительного применения инвариантов. В вашем случае, какие данные необходимы для этого? Требуется ли какая-либо информация, чтобы решить, можно ли зарегистрировать задачу? Например, скажем, у вас есть требование, чтобы пользователь мог иметь не более 3 «todo». В этом случае достаточно хранить таблицу в хранилище «Command Store» (UserId, Todo Count). Вы также можете использовать (UserId, [TodoId]) - то есть. сохраните список идентификаторов todo, чтобы вы могли получить идемпотентность. Вся другая информация о пользователе и задачах будет представлять собой данные запроса и будет находиться в хранилище запросов.

Надеюсь, что имеет смысл.

источник

2014-12-05 11:53:58 ashic

Привет, спасибо за ответ. Да «getTask» - это запрос (я сразу изменил ошибку, потому что я назвал его «CommandQuery», и я имел в виду просто запрос ». Мои вопросы: если имеет смысл или не хранить информацию в базе данных sql (информация, поступающая от команд), а также представление NoSql этой информации. Представление nosql - это хранилище для запроса, и информация является модульной в режиме «запрос». Имеет смысл? – erlangb

Опять же, sql или nosql не обязательно имеют значение. в хранилище команд должно быть только информация, необходимая для принудительного применения инвариантов. Это может означать некоторую информацию, которая находится в хранилище запросов, или она может быть полностью в отдельном формате. Это будет зависеть от вашего конкретного бизнес-сценария. – ashic

Хорошо спасибо! вероятно, я не очень хорошо объяснил, что я имею в виду. Я просто говорю: предположим, если у вас есть бизнес-сценарий, в котором команда хранит информацию в STOREA. И если запрос запрашивает информацию из STOREB. Где STOREA! = STOREB, потому что в информации в STOREB организовано по-другому, какой наилучший подход поддерживать STOREB в обновленной версии STOREA? Я думаю, что одно из преимуществ CQRS определяется разделением проблем между «write «действия и действия« Читать ». Затем, в некоторых случаях, я могу разделить магазины, где данные записываются или читаются. – erlangb

Хотя есть моменты, когда вы, возможно, захотите сохранить команды, обычно нет. Скорее популярный подход заключается в том, чтобы хранить события домена, которые происходят в результате команд. Это называется Event Sourcing. Это сделало бы «STOREA» хранилищем событий или другим способом, потоком событий. «STOREB» обычно называют Read Model. Он имеет де-нормированную структуру, оптимизированную для скорости чтения. Он постоянно обновляется через де-нормализаторы, которые реагируют на конкретные события. Ключевым моментом здесь является то, что часто возникает задержка между создаваемым событием и обновляемой моделью чтения. Это, на мой взгляд, хорошая вещь, но ее нужно учитывать при разработке пользовательского интерфейса.

Для получения дополнительной информации посмотрите на CQRS – A Step-by-Step Guide to the Flow of a typical Application

Я надеюсь, что помогает

источник

2014-12-12 22:39:28 Codescribler

CQRS design: nosql data view

ответ

Смежные вопросы