Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Хотел написать что написали какую то херню. Потом посмотрел на автора. Этот чувак создал geteventstore.com
Если мы рассмотрим CQRS как это написано в вики «метод должен быть либо командой, выполняющей какое-то действие, либо запросом, возвращающим данные, но не одновременно», то он прав. Но только ради этого естественно смысла нет использовать CQRS.
В тех проектах где я сталкивался, всегда использовали:
1. команды — которые создают события(и наоборот), но события важнее
2. база для хранения событий, и вторая база, которую можно получить пробегаясь по всем событиям из первой базы.
Без них лично я не вижу смысла использовать CQRS.
Если мы рассмотрим CQRS как это написано в вики «метод должен быть либо командой, выполняющей какое-то действие, либо запросом, возвращающим данные, но не одновременно», то он прав. Но только ради этого естественно смысла нет использовать CQRS.
В тех проектах где я сталкивался, всегда использовали:
1. команды — которые создают события(и наоборот), но события важнее
2. база для хранения событий, и вторая база, которую можно получить пробегаясь по всем событиям из первой базы.
Без них лично я не вижу смысла использовать CQRS.
Этот чувак создал geteventstore.com
… этот «чувак» первым озвучил термин CQRS, уж если на то пошло.
Но только ради этого естественно смысла нет использовать CQRS.
Почему?
Чувак этот крутой, я в курсе )) У меня 2 проекта используют его EventStore. А вот на другом проекте не смогли перейти, стрессовое тестирование не прошел.
По поводу «почему». Какой смысл усложнять себе жизнь? Ведь клиент отправляя команду, как правило хочет знать, выполнилась она или нет, и если выполнилась то обновить у себя состояние. Проще тогда все делать «по старинке».
А у вас есть другое мнение? Очень интересно послушать.
По поводу «почему». Какой смысл усложнять себе жизнь? Ведь клиент отправляя команду, как правило хочет знать, выполнилась она или нет, и если выполнилась то обновить у себя состояние. Проще тогда все делать «по старинке».
А у вас есть другое мнение? Очень интересно послушать.
Очень часто либо обновленное состояние не нужно вообще (особенно, если говорить о программных клиентах, а не пользовательских), либо клиент и сам его знает (когда команда по суди имеет семантику «обновить сущность на сервере в соответствии с её состоянием на клиенте» или проще «сохранить изменения»).
Ну хорошо, поставим вопрос с другой стороны. Какой плюс в использование CQRS в чистом виде?
Возможность последующего масштабирования, например.
Более быстрые запросы которые просто отдают данные для отображения и при этом полнофункциональная доменная модель для команд. Очень, знаете ли неудобно, когда для отображения грида в котором 3-4 колонки со значениями, для каждой строки приходится загружать весь агрегат целиком.
При этом query модель вообще не позволяет апдейтить сущности в хранилище, и поэтому нельзя испортить консистентность данных сохранив не прошедшие валидацию доменом значения.
При этом query модель вообще не позволяет апдейтить сущности в хранилище, и поэтому нельзя испортить консистентность данных сохранив не прошедшие валидацию доменом значения.
Во-первых, есть домены, где CQRS естественнен: всякое логгирование, аудит и так далее.
Во-вторых, есть технические ситуации, когда клиенту, на самом деле, никто не гарантирует ответа об успешности команды (все удаленные подключения в условиях нестабильной связи).
Во-вторых, есть технические ситуации, когда клиенту, на самом деле, никто не гарантирует ответа об успешности команды (все удаленные подключения в условиях нестабильной связи).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CQRS, UI, основаный на заданиях, Источники событий… ах