если очень хочется поиграться с концепцией - рекомендую начинать с этого: https://www.eventstore.com/

сразу миллион проблем решаются инфраструктурой

ни капли нистрашно)

слабоумие и отвага, это наш подход да

я серьезно - перед тем как пробовать чет свое мутить лучше поиграться с eventstoredb. просто что бы разобраться и не тратить время на кучу нюансов про которые не оч хочется думать первое время

что до CQRS - мощь CQRS там где у тебя моделирование происходит с учетом того что есть команды (операции которые пользователь запускает что бы поменять стэйт системы, что бы что-то произошло) и "команды не должны падать по бизнес причинам". Условно клиент что бы мог кинуть команду на сервер и выстроить UI так что "команда ушла - мне не обязательно ждать результата я могу сразу на UI обновить как будто все сделано".

А сам-то пробовал?:)

читай выше, юзаю ES уже лет 5

и уже не первый проект потому говна хлебнул

ну то есть это реально сложно это не похоже на "просто шину команд" и т.д. (считай что все команды выполняются строго в бэкграунде). И смысл в этом есть только там где либо хочется каких-то гарантий что операции пользователя будут обработаны (нельзя просрать данные пользователя) либо там где высокая конкурентность за ресурсы (аукционы, резервирование билетов, прочие штуки где все хотят купить последний айтем и 99% запросов бы упало из-за гонок). И это все будет влиять на то как флоу пользователя должен работать... Иначе это все просто command pattern + CQS и никакого отношения к CQRS не имеет

но CQRS не про запись в мастер, а четние с реплик, или отдаленно что-то в этом есть?

command/query repsponsibility segregation - это буквально "подход при котором мы разделяем операции на команды и запросы, запросы не меняют стэйт, команды никогда не должны фэйлиться по бизнес логике". То есть именно сам подход к разделению важен. а что ты потом с этим делаешь - просто мастер и проекции, или там еще чего...

ну да, все верно

короч посмотри видосики Уди, его трактовки CQRS мне кажутся наиболее полезными. Как никак они с Грегом себе авторство приписывают

только грэг больше продает event sourcing и у него эта ниша, а у Уди nservicebus и cqrs

я чувствую, как у тебя прям глаза горят беседовать об грамотных подходах ))

благодарю!

> команды никогда не должны фэйлиться по бизнес логике

сомнительно.
а по сути, если хочешь просрать проект, то бери es и миссия будет достигнута спустя пол года.

они не "грамотные", они специфичные достаточно. Просто нынче со всей этой движухой в сторону serverless, offline first и т.д. они становятся чуть чуть более востребованы

что именно сомнительно?