#cqrs Кажется уже как-то писал сюда, что самым грустным в наше | I hate overtime

#cqrs
Кажется уже как-то писал сюда, что самым грустным в нашей индустрии на сегодняшний день я считаю культ карго. Благодаря огромному количеству информационного шума разработка ПО из инженерии превращается в набор лучших практик, которые натягиваются на абсолютно любой кейс. Удивительно то, что забивать гвозди исхитряются всем чем угодно: архитектурными стилями, технологиями и даже процессами. В этом тредике расскажу про проявления этой болячки от которых у меня больше всего бомбит.
Начнем пожалуй с одной из последних таких серебряных пуль. Прошу любить и жаловать CQRS
CQRS -- это эволюция принципа разделения команд и запросов(CQS) Бертрана Мейера, который был призван принести в мейнстримовые языки(в созданный им Eifell) лучшие практики, в частности, local reasoning из набирающих популярность функциональных языков. Основной смысл в том, что вы всегда можете глядя на сигнатуру функции однозначно понять что она делает без нежданчиков типа изменения значения параметров функции или глобального стейта. Таким образом кодец становится сильно проще читать и понимать, что уменьшает так же и порог входа для новых членов команды.
CQS для этого предлагает поделить все методы на запросы и команды, где запросы всегда только возвращают результат, ни коим образом не влияя на состояние каких-то объектов системы, а комманды как раз меняют стейт, но не возвращают ничего кроме ошибки.
CQRS же достаточно сильно развивает эту концепцию обильно сдабривая все это асинхронщиной и канкаренси, что впринципе не мудрено, с учетом того что Грег Янг изобрел ее для решения задач мастабируемости своих приложений. Смысл в том, что мы аккуратно переходим от синхронной архитектуры с логически разделенными частями на чтение и изменение к архитектуре основанной на обмене сообщениями. Основная идея в том, что мы выделяем 3 типа сообщенек: команды, ивенты и нотификации, где ивенты -- это сообщения которые рождаются при любом изменении стейта системы, команды -- это сообщения на которые система обязана отреагировать изменением стейта(и, как следствие, рассылкой ивентов), нотификации -- опциональная штука для уведомления системы о недоменных историях, например чисто техническая инфа или что-то для интеграции с остальным ландшафтом.
Отдельно надо сказать о кверях. Главное допущение всего этого великолепия заключается в многократном превышении нагрузки на чтение нагрузки на запись. Т.о. что бы иметь возможность скейлиться окололинейно до бесконечности нам надо научиться окололинейно и до бесконечности скейлить нагрузку на чтение. Для этого cqrs предлагает во-первых, выделить отдельную подсистему чтения (далее read part RP) от сложной и достаточно неторопливой подсистемы изменения (write part WP) со всеми описанными выше сообщеньками. Т.е. фактически мы сохраняем нашу концепцию cqs'ных кверей, максимально отделяя ее от WP, желательно в отдельный процесс.
Далее, нам надо научиться нашей нагрузкой на чтение не мешать нагрузке на запись. Ну тут все просто, давайте просто читать с реплики! Вот тут вот мы подходим к самому важному на сегодня: cqrs никогда из коробки не даст вам глобальных гарантий выше eventual consistency, которая является самой слабой гарантией консистентности и почти никогда бизнес не устраивает. На самом деле даже для того что бы построить casual consistency систему (что еще может как-то устроить бизнес) придется очень много плясать с бубном. Фактически же, надо очень четко понимать какой уровень консистентности устраивает бизнес и что вам придется навернуть из говна и палок что бы этого достичь. Ведь если у вас пуши на экране вывалятся не в том порядке, то вы, скорее всего этого даже не заметите, а вот если у вас списания и пополнения в бухгалтерской сводке перепутаются, то вам возможно придется придумывать что делать с полотенцем брошеным под ноги.