Command Query Responsibility Segregation

Август 7, 2022

Главная
Информатика
Command Query Responsibility Segregation

Содержание

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

Слайд 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