V
Неспроста @aleksei_t с утра про дурку стикеры просил
Size: a a a
2020 February 12
ЕР
Именно из-за неё был упомянут CQRS
Oℕ
Зачем?
Потому что это дистрибьютед, тебе нужно чтобы все квери строили автоматически вью на основе одного представления команд.
Есть много плохих способов это сделать, но финальный ответ будет - кафка
Есть много плохих способов это сделать, но финальный ответ будет - кафка
AD
двухфазный коммит - нет. Распределенные логические транзакции и итоговая согласованность да. Но что в них плохого
в том что распределённые транзакции плохо само по себе
ЕР
Потому что это дистрибьютед, тебе нужно чтобы все квери строили автоматически вью на основе одного представления команд.
Есть много плохих способов это сделать, но финальный ответ будет - кафка
Есть много плохих способов это сделать, но финальный ответ будет - кафка
Да почему дистрибьютед то?
ЕР
CQRS юзается без ES
DE
В том, что абсолютно всё становится eventually, абсолютно всё становится event-driven, абсолютно всё становится распределённым.
В итоге ты просто получаешь 500 багов и недовольства юзеров из-за расхождений данных в разных кусках экрана, и два года их чинишь, добавляя ещё и ещё сервисы, кеши, паксосы, распределённые локи, САГИ и прочее говно.
Всё, чтобы казаться себе чуть более оопешным. В то время, как это давно синоним слова "обсос"
В итоге ты просто получаешь 500 багов и недовольства юзеров из-за расхождений данных в разных кусках экрана, и два года их чинишь, добавляя ещё и ещё сервисы, кеши, паксосы, распределённые локи, САГИ и прочее говно.
Всё, чтобы казаться себе чуть более оопешным. В то время, как это давно синоним слова "обсос"
CQRS сложен только если использовать с Event Sourcing. Тогда нужна вторая БД и синхронизация эвентами. Если БД одна, то сложности нет.
Oℕ
Да почему дистрибьютед то?
Ну потому что у тебя разные сервисы отвечают за комманд
И квери
И квери
Oℕ
CQRS сложен только если использовать с Event Sourcing. Тогда нужна вторая БД и синхронизация эвентами. Если БД одна, то сложности нет.
Ой тебя в этом чате вообще никто слушать не будет
ЕР
Ну потому что у тебя разные сервисы отвечают за комманд
И квери
И квери
Да, второй сервис может просто в базу SQL-запросы делать. В ту базу в которую сохраняются данные через write-модель
Oℕ
CQRS сложен только если использовать с Event Sourcing. Тогда нужна вторая БД и синхронизация эвентами. Если БД одна, то сложности нет.
Иди потуси в @ebanatics
Oℕ
Да, второй сервис может просто в базу SQL-запросы делать. В ту базу в которую сохраняются данные через write-модель
Чел
YG
Если у вас не CRUD без CQRS никак, ибо модели на чтение и на запись в любом случае начинают расползаться. И приходится костылить всякие mappers dtos.
Oℕ
Это уже дистрибьютед
YG
А коммитить можно целиком и все и без распределенных транзакций, просто это наоборот как плюс можно рассматривать.
ЕР
Это уже дистрибьютед
Что ты сервисом называешь?
Oℕ
Что ты сервисом называешь?
а ты
Oℕ
Если у вас не CRUD без CQRS никак, ибо модели на чтение и на запись в любом случае начинают расползаться. И приходится костылить всякие mappers dtos.
у нас CRUD