Роман Неволин «Почему ваша архитектура функциональная и как с этим жить»

Если ваш проект — не дремучее легаси, то, скорее всего, он имеет в основе какую-нибудь модную архитектурную концепцию. CQRS, например. Или DDD. А может, Actor Model? Впрочем, без разницы — все они так или иначе связаны с миром функционального программирования. И даже если на вашей футболке написано «OOP only and forever», вы, вероятно, каждый день пишете функциональный код.

Как так вышло, в чем это выражается, как с этим жить и чем понимание принципов функциональной архитектуры может помочь улучшить ваш код? Обо всем этом мы с вами и поговорим.

Transcript

1. Почему ваша архитектура - функциональная (и как с этим жить)
2. Здравствуйте, меня зовут Роман и я люблю функциональное программирование
5. На самом деле нет ООП неплохо взаимодействует с функциональным подходом
6. О чем мы сегодня? • Что такое функциональное программирование и почему оно важно прямо сейчас
7. О чем мы сегодня? • Что такое функциональное программирование и почему оно важно прямо сейчас • Какие идеи возникли вокруг функционального подхода и как применить их в каждодневной разработке
8. О чем мы сегодня? • Что такое функциональное программирование и почему оно важно прямо сейчас • Какие идеи возникли вокруг функционального подхода и как применить их в каждодневной разработке • Как эти идеи используются в современной архитектуре
9. Часть первая Почему вдруг функционального программирования стало так много (и что это вообще такое)
10. Что такое функциональное программирование?
11. Функциональное программирование — парадигма, в которой ход выполнения программы описывается переходами данных между различными состояниями
12. ID CardData
13. CardDat CardImage
14. CardImage Response
15. CardData CardImage CardData ID ID Request Response CardImage
16. Request Response
17. Чем характерна чистая функция? • Не изменяет состояние
18. Чем характерна чистая функция? • Не изменяет состояние • Не производит побочных эффектов
19. Чем характерна чистая функция? • Не изменяет состояние • Не производит побочных эффектов • Выдает одинаковый результат «на выходе» при одинаковых входных параметрах
20. И за это мы получаем • Параллельность «из коробки»
21. И за это мы получаем • Параллельность «из коробки» • Простота отладки и тестирования
22. И за это мы получаем • Параллельность «из коробки» • Простота отладки и тестирования • Отказоустойчивость
23. И за это мы получаем • Параллельность «из коробки» • Простота отладки и тестирования • Отказоустойчивость • Развертывание без перезапуска
24. В какой-то момент все это стало очень важным
27. Конкурентность — это сложно. И дорого.
28. You don't need to control shared state If you don't have shared state
29. Итого, функциональное программирование помогает нам решать современные проблемы масштабирования
30. Итого, функциональное программирование помогает нам решать современные проблемы масштабирования
31. Часть вторая Интересные идеи из функционального мира (и способы их использовать вне этого мира)
32. Функция как объект
36. А что, если представить высокоуровневый код как чистую функцию?
37. Request Response
38. CardData CardImage CardData ID ID Request Response CardImage
41. FUNCTIONAL CODE
42. github.com/jbogard/MediatR
43. А как насчет логов, авторизации и прочей валидации?
44. Request ValidatedRequ
46. F# INSIDE
49. Плохие новости — на C# это выглядит неоднозначно :(
51. habr.com/ru/post/267231
52. Хорошие новости — можно просто кидаться исключениями :)
60. Как все-таки взаимодействовать с внешним миром?
61. Немного выводов • Всевозможные валидации и авторизации можно сделать частью пайплайна
62. Немного выводов • Всевозможные валидации и авторизации можно сделать частью пайплайна • Самый простой способ обработки ошибок — правильные бизнес исключения (но есть варианты)
63. Немного выводов • Всевозможные валидации и авторизации можно сделать частью пайплайна • Самый простой способ обработки ошибок — правильные бизнес исключения (но есть варианты) • Для получения всех преимуществ функционального пайплайна нужно избавиться от побочных эффектов
64. Немного выводов • Всевозможные валидации и авторизации можно сделать частью пайплайна • Самый простой способ обработки ошибок — правильные бизнес исключения (но есть варианты) • Для получения всех преимуществ функционального пайплайна нужно избавиться от побочных эффектов • Но можно получать не все
65. Полнота функций
70. На самом деле, стало лучше! • Cигнатура функции более точна
71. На самом деле, стало лучше! • Cигнатура функции более точна • К нашим услугам все фичи, связанные с nullability
73. На самом деле, стало лучше! • Cигнатура функции более точна • К нашим услугам все фичи, связанные с nullability • Теперь получить null reference чуть сложнее
74. docs.microsoft.com/en-us/dotnet/csharp/nullable-references Nullable contexts • enable • disable • safeonly • warnings • safeonlywarnings
76. Забавный факт, Optional — это монада
77. Забавный факт, Optional — это монада Result, кстати, тоже
78. Монады нужны для связывания цепочки преобразований
80. Optional (или Nullable) — это промежуточное состояние
83. Модели вместо Optional полей • Уменьшается количество проверок
84. Модели вместо Optional полей • Уменьшается количество проверок • Типы в коде становятся более «описательными»
85. Модели вместо Optional полей • Уменьшается количество проверок • Типы в коде становятся более «описательными» • Сложнее передать неверное значение
86. Модели вместо Optional полей • Уменьшается количество проверок • Типы в коде становятся более «описательными» • Сложнее передать неверное значение • Приходится писать больше моделей
89. Обертки вместо примитивов • Мы точнее описываем назначение функции
91. Обертки вместо примитивов • Мы точнее описываем назначение функции • Передать неверное значение намного сложнее
92. Обертки вместо примитивов • Мы точнее описываем назначение функции • Передать неверное значение намного сложнее • В создание типа можно добавить валидацию
95. А еще наш код становится ближе к иммутабельности
96. Часть третья Как функциональное программирование используется в архитектуре (и что мы можем сделать не так)
97. CQRS
99. CQRS • Код с побочными эффектами отделен от кода без них
100. CQRS • Код с побочными эффектами отделен от кода без них • Чтение легко масштабируется
101. CQRS • Код с побочными эффектами отделен от кода без них • Чтение легко масштабируется • Мы можем частично использовать преимущества функционального пайплайна
102. youtube.com/watch?v=qJPwSvDLmQE
103. Actor Model
105. Actor Model • Актор может служить имплементацией «чистого» пайплайна
106. Actor Model • Актор может служить имплементацией «чистого» пайплайна • Модель позволяет легко изолировать «грязную» логику
107. Actor Model • Актор может служить имплементацией «чистого» пайплайна • Модель позволяет легко изолировать «грязную» логику
108. youtube.com/watch?v=wRxO5ky7S8g
109. DDD
110. DDD • Все объекты и их состояния должны соответствовать единому языку
111. DDD • Все объекты и их состояния должны соответствовать единому языку • Состояния должны быть изолированы
112. DDD • Все объекты и их состояния должны соответствовать единому языку • Состояния должны быть изолированы • Мы описываем переходы между этими состояниями
113. DDD • Все объекты и их состояния должны соответствовать единому языку • Состояния должны быть изолированы • Мы описываем переходы между этими состояниями • ФП способствуем двум важнейшим целям — избавить бизнес-логику от сторонних зависимостей и корректно описать состояния
115. Проблема Смешивание «чистого» и «грязного» кода
116. И за это мы получаем • Параллельность «из коробки» • Простота отладки и тестирования • Отказоустойчивость • Развертывание без перезапуска
117. Проблема Многократная обработка ошибок
118. Проблема Использование промежуточного состояния в качестве поля
119. Проблема Одержимость примитивами
120. Итого • Чтобы воспользоваться отдельными преимуществами функционального подхода, нет нужды писать все функционально
121. Итого • Чтобы воспользоваться отдельными преимуществами функционального подхода, нет нужды писать все функционально • Если изолировать те места, где ваш код «чистый» — можно очень сильно упростить себе масштабирование и многое другое
122. Итого • Чтобы воспользоваться отдельными преимуществами функционального подхода, нет нужды писать все функционально • Если изолировать те места, где ваш код «чистый» — можно очень сильно упростить себе масштабирование и многое другое • А отдельные идеи из функционального программирования неплохо применяются вне зависимости от стиля
123. Спасибо! nevoroman@gmail.com nevoroman