мы реализовывали эту связку в своем биллинге. И удовольствия, действительно, никакого. Поменялся ивент (а в базе уже лежит пачка ивентов старой версии) — нужно писать адаптеры для того, чтоб аггрегат мог в принципе развернуться, иначе весь прод лежит. В общем, не сказал бы, что store в redux очень похож на eventsourcing, все таки на фронте состояние хранится относительно кратковременно и с такими проблемами наверняка не сталкиваются)
1) в первую очередь она просто возьмет на себя ответственность за создание запросов/команд и в этом случае будет единственной точка входа для этого. Что полезно
2) Вот говорится как раз о моменте, описанном в скобочках. Передача конкретных обработчиков в конструкторе позволит контролировать сложность класса и вовремя понять, что начинает становиться God-объектом и разделить. При использовании диспетчера это не ясно
3) Это point-of-failure. Если Вы сами пишете эти методы — некоторое время можно будет рассчитывать на то, что название методов адекватно отражает происходящее в них (а по прошествии некоторого времени — уже нет)
В ином же случае помимо названий методов (которые легко посмотреть в студии) придется уже пересматривать эти методы для того, чтоб понять что именно там происходит
new не так плох, просто если класс зависит от фабрики, то из сигнатуры конструктора очевидно, какую ответственность он на себя берет. То есть вот этот контроллер создает внутри запросы и по обработчикам видно — какие именно запросы он создает (и обрабатывает), более того, контроллеры это медиаторы, которые должны выполнять как можно меньше работы, но при этом они могут содержать большое количество зависимостей для делегирования обязанностей между ними.
Достоинства CQRS
Меньше зависимостей в каждом классе;
честно говоря, при такой реализации способ уменьшения зависимостей кажется спорным. Во-первых мы прибегаем к антипаттерну диктатор (по Марку Симену), когда зависимости мы создаем напрямую через new. На мой взгляд было бы уместнее использовать что-то вроде абстрактной фибрики запросов, тогда в том числе по сигнатуре контроллера было понятно, что он создает запросы. Ну и в плане класса диспетчера, который по факту тоже является антипаттерном сервислокатор, он создает кажующуюся простоту контроллера. На самом деле он не уменьшает количество зависимостей ( и как следствие сложность) класса, он просто скрывает их реальное количество. В итоге мы жертвуем простотой класса с точки зрения понимания его обязанностей и, как следствие, эффективностью рефакторинга. Было бы рациональнее внедрять конкретные обработчики через конструктор, при этом класс стал бы гораздо понятнее
мы реализовывали эту связку в своем биллинге. И удовольствия, действительно, никакого. Поменялся ивент (а в базе уже лежит пачка ивентов старой версии) — нужно писать адаптеры для того, чтоб аггрегат мог в принципе развернуться, иначе весь прод лежит. В общем, не сказал бы, что store в redux очень похож на eventsourcing, все таки на фронте состояние хранится относительно кратковременно и с такими проблемами наверняка не сталкиваются)
ну да, CQRS нужен для масштабирования на чтение
1) в первую очередь она просто возьмет на себя ответственность за создание запросов/команд и в этом случае будет единственной точка входа для этого. Что полезно
2) Вот говорится как раз о моменте, описанном в скобочках. Передача конкретных обработчиков в конструкторе позволит контролировать сложность класса и вовремя понять, что начинает становиться God-объектом и разделить. При использовании диспетчера это не ясно
3) Это point-of-failure. Если Вы сами пишете эти методы — некоторое время можно будет рассчитывать на то, что название методов адекватно отражает происходящее в них (а по прошествии некоторого времени — уже нет)
В ином же случае помимо названий методов (которые легко посмотреть в студии) придется уже пересматривать эти методы для того, чтоб понять что именно там происходит
new не так плох, просто если класс зависит от фабрики, то из сигнатуры конструктора очевидно, какую ответственность он на себя берет. То есть вот этот контроллер создает внутри запросы и по обработчикам видно — какие именно запросы он создает (и обрабатывает), более того, контроллеры это медиаторы, которые должны выполнять как можно меньше работы, но при этом они могут содержать большое количество зависимостей для делегирования обязанностей между ними.
если минусуете — делайте это аргументированно )
public ActionResult SearchUsers(string searchString)
{
var query = new FindUsersBySearchTextQuery(searchString);
Достоинства CQRS
Меньше зависимостей в каждом классе;
честно говоря, при такой реализации способ уменьшения зависимостей кажется спорным. Во-первых мы прибегаем к антипаттерну диктатор (по Марку Симену), когда зависимости мы создаем напрямую через new. На мой взгляд было бы уместнее использовать что-то вроде абстрактной фибрики запросов, тогда в том числе по сигнатуре контроллера было понятно, что он создает запросы. Ну и в плане класса диспетчера, который по факту тоже является антипаттерном сервислокатор, он создает кажующуюся простоту контроллера. На самом деле он не уменьшает количество зависимостей ( и как следствие сложность) класса, он просто скрывает их реальное количество. В итоге мы жертвуем простотой класса с точки зрения понимания его обязанностей и, как следствие, эффективностью рефакторинга. Было бы рациональнее внедрять конкретные обработчики через конструктор, при этом класс стал бы гораздо понятнее