1: Command Query Responsibility Segregation ИЛИ ПРОСТО ЦЭКУЭРЭС
2: Но для начала выкинем R из CQRS CQS – Command Query Separation, разделение команд и запросов Основная идея CQS заключается в том, что любые методы могут быть только двух типов: - Queries – возвращают результат, не изменяя состояние объекта - Commands - изменяют состояние объекта, не возвращая значение
3: Не-CQS-ный код
4: Превращается в CQS-ный код
5: А вот теперь CQRS CQRS – Command Query Responsibility Segregation, разделение ответственности на команды и запросы Та же идея, что и в CQS, но на более высоком уровне – на уровне всей системы Для изменения состояния системы используем Command Для выборки данных о состоянии системы используем Query
6: CRUD-сценарий
7: Что происходит дальше? - У нас есть концептуальная модель, которая взаимодействует с основными объектами нашего домена - Мы стараемся сделать наше хранилище наиболее приближенным к нашим данным - Нам требуется выбирать и отображать все более сложно связанные данные, в том числе отчеты - Наши объекты становятся все более сложными с большим количеством вспомогательных полей - Вслед за объектами усложняется и хранилище - Появляется лишнее для команд, нужное только для запросов
8: CQRS-сценарий
9: CQRS-сценарий с разными хранилищами
10: Эволюция команд и запросов на практике Акт первый
11: Эволюция команд и запросов на практике Акт второй
12: Эволюция команд и запросов на практике Акт третий
13: Эволюция команд и запросов на практике Акт четвертый
14: Эволюция команд и запросов на практике Занавес - Меньше зависимостей в каждом классе - Соблюдается принцип единственной ответственности - Маленький класс проще заменить - Маленький класс проще тестировать - В целом дизайн кода однотипный и понятный - При расширении функциональности системы сложность дизайна растет почти линейно
15: CQRS может быть на любом уровне Тенденция рефакторинга: - Растет количество классов - Растет количество методов в каждом классе - Растет количество зависимостей каждого класса - Разбиваем их на Command и Query Вместо больших классов с множеством зависимостей мы движемся в сторону большого количества маленьких однотипных классов, каждый из которых отвечает за единственное бизнес-правило
16: Наш недо-CQRS
17: Наш недо-CQRS
18: Наш недо-CQRS
19: Наш недо-CQRS
20: Наш недо-CQRS
21: Наш недо-CQRS
22: Как это выглядит в бою?
23: Как это выглядит в бою?
24: Почему недо-CQRS? Работа по большей части с CRUD При выполнении команды хочется тут же получить какой-то результат и использовать его для отрисовки UI После добавления элемента часто необходимо перенаправить пользователя на страницу с только что добавленным элементом Мы изменяем поля CommandContext-ов, мы сожалеем