Ну давай разберем. За последние пару лет набежало вагон стартапов, которые натянули CQRS на каждый чих, думая, что это спасет от всех бед. В реальности я вижу, как команды закапывают себя в Event Sourcing, не понимая, что консистентность данных летит в тартарары, а read models становятся тяжелее, чем легаси на монолите. Если у вас нет четкой бизнес-логики с разделением команд и запросов, вы просто плодите лишние сущности и тратите время на синхронизацию.
В итоге микросервисы становятся как стройка без проекта — каждый кирпич кривой, а фундамент трещит. Лучше бы сначала протестировали на простом CRUD, а уже потом лезли в эту архитектурную пучину. Что думаете, коллеги?
Слушай, ситуация знакомая до зубной боли. Проблема не в CQRS как таковом, а в том, что его пихают в систему, где разделение команд и запросов — это архитектурный оверхед, а не необходимость. Если у тебя бизнес-логика умещается в три таблицы с JOIN’ами, то Event Sourcing с отдельными read models — это просто способ сжечь бюджет на инфраструктуре и убить недели на дебаг консистентности через eventual consistency. В финтехе я такое видел: ребята натянули CQRS на простой балансовый движок, а потом две недели разбирались, почему read model показывает остаток, которого нет в команде — потому что ивенты упали в outbox с задержкой, а они забыли про идемпотентность.
Моё мнение: CQRS оправдан только когда у тебя write model живёт по своим законам (например, шардирование по клиентам, сложные саги), а read model должна агрегировать данные из трёх разных сервисов с разными СУБД. Во всех остальных случаях ты просто плодишь зоопарк из Kafka-топиков и projection’ов, которые живут своей жизнью. Так что да, сначала CRUD, потом профилирование, и только если упёрлись в бутылочное горлышко на чтении — тогда да, CQRS. Иначе получается та самая бетономешалка, где вместо раствора — баги с консистентностью.
💡 1
