Основы CQRS
Комментарии (6)
vintage
18 июля 2017 в 10:58
0↑
↓
Кроме возврата значения, здесь также определено, что в случае валидного email сразу присваивать его значение (делаем Command) полю Email.
То есть достаточно назвать метод «TryChangeEmail», который пытается изменить email и возвращает статус изменения, и вашей проблемы с недопониманием что делает метод не будет. Разделение на 2 метода тут не требуется.
Еще важнее, что эти два уровня могут находиться даже в двух разных звеньях (tiers) и оптимизироваться раздельно, никак не затрагивая друг друга.
Командам как правило необходимо делать запросы в процессе работы. И какой толк в этом случае от разделения команд и запросов, если они всё равно получаются сильно связанными?
raveclassic
18 июля 2017 в 11:09 (комментарий был изменён)
0↑
↓
Запросы лучше делать не из команд, а из process-менеджеров. Для таких транзакций тут не хватает event sourcing.
-
vintage
18 июля 2017 в 11:53 (комментарий был изменён)
0↑
↓
Больше абстракций богу абстракций :-)
18 июля 2017 в 11:27
0↑
↓
Командам нужно делать в процессе работы запросы к базе, но эти запросы не будут буквой Q в CQRS.
-
vintage
18 июля 2017 в 11:51
0↑
↓
А смысл дублировать код запросов?
18 июля 2017 в 12:31 (комментарий был изменён)
0↑
↓
Вообще CQRS имеет смысл быть для высоко нагруженных систем.
Одна БД для записи информации, 4 БД для чтения информации. Иначе зачем делить логику, как мне кажется это методология или новомодное словечко вечно вырывается из контекста!
Хотелось бы узнать у Бертрана Мейера какое у него было железо !
https://ru.wikipedia.org/wiki/CQRS
На практике, CQRS дает возможность пропустить все проверки утверждений в действующей системе, чтобы повысить её производительность, не боясь того, что это изменит её поведение. CQRS также предотвращает возникновение некоторых гейзенбагов.
Как я и говорил для повышения производительности !
