Иван Кожин «Saritasa Tools или ещё один подход к архитектуре приложения»

Порой сложно работать с большими системами, особенно если они достались в наследство, и уж тем более если в команде много неопытных разработчиков. В таких случаях на помощь может прийти практика типовой архитектуры. Иван расскажет о подобной архитектуре и своей библиотеке «Saritasa Tools» для реализации такого рода задач.

Transcript

1. Saritasa Tools Или ещё один подход к архитектуре приложения Иван Кожин, Очень Интересно 1
2. Наш зоопарк проектов 2
3. Случай на проекте Заказчик: У меня при заказе товара происходит ошибка… 3
4. Случай на проекте 4
5. Случай на проекте Мы: Ок, а какой аккаунт вы использовали? Заказчик: test@someproject.com Мы: На какой странице и какой продукт вы запрашивали? … 5
6. Случай на проекте #2 6
7. 7 Ну, извините...
8. Цели • Разработать гибкую типовую архитектуру для наших проектов. 8
9. Цели • Разработать гибкую типовую архитектуру для наших проектов. • Заложить в архитектуру возможность журналирования событий в проекте. 9
10. Цели • Разработать гибкую типовую архитектуру для наших проектов. • Заложить в архитектуру возможность журналирования событий в проекте. • Предоставить возможность анализа состояния системы в различное время. 10
11. Цели • Разработать гибкую типовую архитектуру для наших проектов. • Заложить в архитектуру возможность журналирования событий в проекте. • Предоставить возможность анализа состояния системы в различное время. • Улучшить возможности интеграционного тестирования наших проектов. 11
12. Паттерн «Команда» CreateWorklog Command CreateWork log() Команда Обработчик 12
13. CQRS 13 Command-query responsibility segregation
14. CQRS 14
15. Проект Saritasa Tools • Связывание команды и обработчика • Сохранение списка команд • Сохранение дополнительной информации • ... 15
16. Saritasa Tools Messages 16 Common Misc Domain Emails EF6 EFCore1 Messages PSGallery
17. Сообщения Пользователи Внутренние задачи Веб-сервисы Message Наше приложение 17
18. Типы сообщений Сообщение (Message) Команда Событие Запрос 18
19. Сообщения Middleware 1 Middleware 2 Ваш код (controller action, service handler, etc) Middleware 3 Message Message Message Pipeline 19
20. Pipelines 20 Commands Pipeline Queries Pipeline Events Pipeline Pipelines
21. Pipelines • Commands Pipeline - Отвечает за изменение состояния приложения (например, запись в хранилище, файлы). 21
22. Pipelines • Commands Pipeline - Отвечает за изменение состояния приложения (например, запись в хранилище, файлы). • Query Pipeline - Используется для запросов состояния приложения. 22
23. Pipelines • Commands Pipeline - Отвечает за изменение состояния приложения (например, запись в хранилище, файлы). • Query Pipeline - Используется для запросов состояния приложения. • Events Pipeline - События, происходящие в командах. Могут иметь несколько обработчиков. 23
24. Pipeline - создание 24
25. Middleware (слой) 25
26. Middleware - добавление 26
27. Middleware - добавление 27
28. Message Context • идентификатор (GUID); • сообщение (данные); • статус; • дата создания; • исключение (если произошло); • дополнительные данные (словарь); • Сервис-провайдер (IServiceProvider); 28
29. Статусы сообщений • NotInitialized; • Processing; • Completed; • Failed; • Rejected; 29
30. Repository Middleware • Сообщения могут быть сохранены для: ◦ ведения журнала; ◦ повторного выполнения; ◦ анализа; • Можно установить фильтр. • Поддерживаемые хранилища: ◦ ADO.NET ◦ файлы ◦ Elasticsearch ◦ Loggly ◦ веб-сервис ◦ JSON ◦ ... 30
31. Формат сообщения 31
32. Формат сообщения 32
33. Формат сообщения 33
34. Формат сообщения 34
35. Формат сообщения 35
36. Формат сообщения 36
37. Формат сообщения 37
38. Формат сообщения 38
39. Repository Middleware - Инициализация 39
40. ADO.NET Repository 40
41. Middleware Repositories - фильтрация 41
42. Command (команда) • Изменяет состояние приложения. • Команда и обработчик — разные сущности. • Может возвращать результат. 42
43. Пример команды 43
44. Handler (обработчик) 44
45. Регистрация обработчиков 45
46. Выполнение 46
47. Выполнение Locator Resolver Executor Поиск обработчика Создание класса обработчика Выполнение Поиск pipeline, формирование контекста сообщения и передача первому слою. 47
48. Внедрение зависимостей 48
49. Внедрение зависимостей • IMessagePipelineContainer - Singleton • IMessagePipelineService - Transient (Scoped) ◦ Pipeline Container ◦ IServiceProvider IMessagePipelineService • Container • Service Provider 49
50. Внедрение зависимостей 50
51. Внедрение зависимостей 51
52. Query Pipeline 1. Не изменяет состояние. 2. Рекомендуется использовать в том случае, если необходимо журналировать аргументы метода и результат. 52
53. Query Pipeline 53
54. Query Pipeline 54
55. Query Pipeline - реализация 55
56. Query Pipeline - реализация 56
57. Events Pipeline CreateUserCommand UserCreatedEvent Отправить e-mail Обновить статистику ... 57
58. Events Pipeline - Event Class 58
59. Events Pipeline - Event Handler 59
60. Events Pipeline - Raise Event 60
61. Собственный middleware 61
62. Производительность 1. Замена рефлексии кодогенерацией. 2. Кэширование. 62
63. Производительность 63
64. Производительность 64
65. Производительность Кеширование делегатов дало увеличение производительности выполнения команд примерно в два раза. Было Стало 65
66. Использование в тестировании Наше приложение WebEndpoint Saritasa.Tools.Console MessagesMonitor JSON-файл Сеть 66
67. Использование в тестировании 67
68. Лог сообщений Message 1 Message 2 Message 3 ~Event Sourcing 68
69. Структура проекта • Domain ◦ Commands ◦ Entities ◦ Events ◦ Handlers ◦ Queries ◦ ... 69
70. А как же “легаси”? 70
71. “Легаси” 1. Не всё так просто, зависит от проекта. 71
72. “Легаси” 1. Не всё так просто, зависит от проекта. 2. Можно подключить библиотеку и использовать там, где журналирование наиболее необходимо. 72
73. “Легаси” 1. Не всё так просто, зависит от проекта. 2. Можно подключить библиотеки и использовать там, где журналирование наиболее необходимо. 3. Переделывать при рефакторинге. 73
74. Что получилось? • Унифицировать архитектуру проектов. 74
75. Что получилось? • Унифицировать архитектуру проектов. • Упростить отладку при возникновении сбоев. 75
76. Что получилось? • Унифицировать архитектуру проектов. • Упростить отладку при возникновении сбоев. • Ввести интеграционное тестирование на основе команд. 76
77. Что получилось? • Унифицировать архитектуру проектов. • Упростить отладку при возникновении сбоев. • Ввести интеграционное тестирование на основе команд. • Осуществлять простой мониторинг приложения (больше данных о том, что происходит внутри). 77
78. Над чем надо работать • Всё ещё бета. 78
79. Над чем надо работать • Всё ещё бета. • Нет нормальных средств для сбора статистики. 79
80. Над чем надо работать • Всё ещё бета. • Нет нормальных средств для сбора статистики. • Интерфейс пользователя для просмотра сообщений в разработке. 80
81. Над чем надо работать • Всё ещё бета. • Нет нормальных средств для сбора статистики. • Интерфейс пользователя для просмотра сообщений в разработке. • Всё ещё находятся баги. 81
82. Над чем надо работать • Всё ещё бета. • Нет нормальных средств для сбора статистики. • Интерфейс пользователя для просмотра сообщений в разработке. • Всё ещё находятся баги. • Документация :) 82
83. И еще один вывод Фреймворк - это сложно 83
84. Кто помогал... 84
85. Спасибо за внимание! • https://github.com/Saritasa/SaritasaTools • https://saritasa-tools.readthedocs.io/en/latest/ Вопросы? 85