В докладе мы рассмотрим этапы развития приложения, начиная от монолитного Web приложения, до распределенной платформы по управлению бизнес-процессами. Покажем этапы развития, задачи и вызовы, которые возникали на каждом их них. Проанализируем различные аспекты, влияющие на развитие архитектуры, такие как бизнес-требования, технологические тренды и возможные ограничения.

1. Вызовы при разработке
enterprise продукта
Никонов Владимир
Terrasoft

2. Особенности enterprise
• Продукт = основа бизнеса
• Размер
• Поддержка пользователей и жизненный цикл продукта

3. Основа бизнеса
• Скорость
• Стоимость
• Стабильность

4. SCRUM

5. SCRUM & ENTERPRISE (SAFe)

6. Поддержка

7. Развитие технологий
• Постоянно
• Лавинообразно
• Имеет конкурентную природу

8. Релизы
• 16 релизов за 6 лет
• частота обновления 2011 - 2015 – 3 раза в год (200+ клиентов)
• частота обновления 2016 - 2017 – 1 раз в месяц (600+ клиентов)

9. Software engineer
• Programmer
• Tester
• System Administrator
• DevOps
• Software engineer

10. Задачи платформы
• В приложении существует возможность создать бизнес-процессы
• Приложение позволяет быстро создавать UI и новые сущности
• Реализовать базовая бизнес-функциональность
• Реализовать возможность изменять/расширять функциональность

11. Часть 1: Начало

12. Фундамент
• C# - основной язык разработки
• Реализация собственного UI
• Silverlight для реализации сложных компонент
• Дизайнеры системы
• Реализация возможностей “на вырост”
• Solution = 50+ проектов
• Собственный ORM
• Динамическая генерация кода для настроек пользователя

13. ASP.Net WebForm

14. Компоненты

15. KISS
• Init
• Load
• Complete
• <Event>

16. Бизнес логика

17. ASP.Net WebForm
+
•Привычный UX
•Возможность доработок
-
•Объём работ
•Асинхронность событий
•Время отклика

18. Дизайнер страниц

19. Дизайнер объектов

20. Дизайнер бизнес процессов

21. Схемы
• Разделение метаданных и кода
• Дизайнеры работают с метаданными
• Генераторы преобразовывают метаданные в код который
используется в runtime
• Генераторы опираются на атрибуты а не конкретные классы

22. Дизайнеры
+
•Простота понимания
•Скорость разработки
•Фундамент для
расширяемости
-
•Сложность дизайнера
•Возможность расширения
•Поддержка бизнес кода

23. YAGNI
• Наследование 1 - 1
• Поддержка enum
• Механизм вычисляемых колонок
• Списки изображений
• Локализированные изображения
• Системы резервного восстановления

24. 50 проектов
• 5 крупных архитектурных изменений за 6 лет
• 70% механизмов, созданных на старте работают
• Собственный ORM не является проблемой

25. Динамическая компиляция
• Все доработки клиентов попадают в сборку в момент применения
изменений
• Сервис динамической компиляции отчётов

26. Обновление клиентов
• Трансформация БД
• Трансформация метаданных

27. Выводы
• KISS & YAGNI
• Риски тех.долга
• Храните намерения а не результаты

28. Часть 2: Рост

29. Проблемы
• Невозможность выгрузки assembly из памяти
• Конфликты разных версий библиотек
• Превышение максимального количества строк в одной assembly
• Невозможность использование стандартных конструкций языка

30. Решения
• Разделение рабочих пространств на отдельные приложения
• Использование сервера хранения сессий (redis)
• Переработка генераторов
• Создание нового типа схемы – SourceCode (чистый C#)
• Использование фабрики с возможностью управлять маппингом
через атрибуты

31. Часть 3: SPA + Пакеты

32. Задачи
• UX
• Скорость отклика интерфейса
• Обновление клиентов
• Длительное время компиляции
• Сложная иерархическая структура рабочих пространств

33. Решение
• Полное разделение frontend-a и backend-a (AMD + MVVM + JS)
• Реализация возможности создания собственных web сервисов
• ROS сервисы
• Физическое разделение кода по пакетам
• Компиляция через .net модули с автоматической разбивкой классов
• Все рабочие пространства системы реализованы отдельными
приложениями и равноправны

34. Часть 4: SPA v2

35. Шахматка

36. DIFF & APPLY
• Любой объект может быть получен из пустого путем конечного
количества изменений (insert, set, merge, delete) применённых
последовательно
• Изменения представляют собой элементарные операции
• Изменения хранятся в виде плоского массива
• Механизм применения изменений учитывает не только порядок
изменений в массиве но тип операций

37. Часть 5: Облачные сервисы

38. Email рассылки
• Реализация независимого headless приложения
• Percona
• RabbitMQ
• Двухсторонняя интеграция c CRM
• Внедрение систем сборки и тестирования для разработки
• Интеграция с системой ведения релизов
• Реализация механизмов и регламентов поставки изменений в
облако

39. Часть 6: Continuous Integration

40. Автоматизация
• Тестирования
• Контроля

41. Тесты

42. Контроль

43. Контроль
• SonarQube
• PVS
• FxCop
• StyleCop

44. Часть 7: Ускорение

45. Development & Runtime
• Стандартный стек инструментов для каждого типа задач
• C#
• JavaScript
• SOA как инструмент горизонтального роста
• Разделение данных и метаданных

46. Часть 8: Завтра

47. Часть 8: Завтра
• MPP
• Big Data
• AI
• Оркестрация

48. Заключение
• Изменения требований и ошибки реализации – процессы которые
не кончаются
• Скорость разработки и доставки изменений не должны зависеть от
размера приложения
• Идеи в которые вы инвестировали сегодня, завтра станут вашим
фундаментом