подхода значится
"Безопасность. Разделение операций позволит настроить более гибкую систему доступа.
"
Как усиливается безопасность? В типичном круде операции и так разделены, речь об этом? Потому что я до этого момента думал, что CQRS - это разделение API вообще на разные бэкенды (и базы, опционально)
ну тут автора надо спрашивать что он имел ввиду. Или хотя б статью прочитать полностью. могу сразу сказать что... - он не говорит про "усиливает безопасность", он говорит про "дает больше гибкости". Как раз за счет физического разделения систем на подсистему "меняющую стэйт" и "дает почитать". Тут тебе и про более простой способ выстраивания всяких юзер активити логов, и про авторизацию которая может по разному быть организована на read/write части, а может и не быть. Какие-нибудь ACL можно например как ту же query часть воспринимать и строить свою модель
вообще его пункты про преимущество CQRS не совсем корректны. Я бы такие написал - независимое масштабирование - то что у него только с ремаркой что это важно ТОЛЬКО когда у нас паттерны использования данных для чтения и записи сильно различаются. гуглить про collaborative domain. если у нас нет collaborative части то толку от CQRS тут резко меньше по сравнению со сложностью. - оптимизированные схемы данных - опять же - только для обеспечения предыдущего пункта и только для того что бы "разные паттерны работы с данными поддерживать". Для типичных Крудов например эти паттерны одинаковые и если нет колаборативной части то у нас нет таких проблем с локами и тд. - безопасность - ничего толком оно не дает на самом деле. Само по себе. Все это может вытекать из того факта что мы можем разные модели строить. А можем и не строить. - разделение проблем - и да и нет. Тут не про классы а про юзкейсы, домены, контексты и вот это все. Разделение вопросов по отказоустойчивости и т.д. но не про "классы". Это херь какая-то. - более простые запросы - дублирует пункт оптимизации схемы данных. - не требует 2 хранилищ данных - так же как микросервисы не требуют того что бы "физически" были разные базы и т.д. Логическое разделение схемы. Это не плюс, это просто пояснение.
а вообще в закрепе есть курс Уди Дахана где он хорошо объясняет что такое CQRS зачем оно надо и что стоит 10 раз подумать что бы это юзать. Лучше пытаться сводить работу к круду и юзать штуки типа CQRS где прям оч надо. хороший пример - у тебя может быть какой-то очень узкий кейс связанный с документами или каталогом товаров. И там может быть нужен CQRS. но это может потащить в себя всякие круд кейсы типа "обновить описание товара документа" или еще чего. На этот случай предлагается домены разделить на "draft" и "execute" стадии. Мол мы сначала редактируем драфты а потом их публикуем. И вот в момент публикации данные могут перетекать в подсистему с CQRS а в draft у нас тупой круд.
Обсуждают сегодня