В последнее время часто говорят о HighLoad-системах. Обычно для них выбирается распределенная архитектура, которая обеспечивает масштабируемость, надежность, производительность и достаточную гибкость.
Преимущества таких систем более-менее понятны и широко освещены, но информации о том, почему важно тщательно прорабатывать требования и как это делать, мало. Аналитик ИТ-компании SimbirSoft Адель Гарифов попробует пролить свет на эту проблему. В статье автор расскажет, какие базовые требования важно учесть и как они влияют на выбор архитектуры системы и результат в целом. Туториал содержит практические советы по детализации свойств архитектуры в разрезе функциональных требований. Это поможет читателям сформировать новый подход к проработке требований будущего продукта и заложить верную архитектуру.
Небольшое отступление
HighLoad-система – продукт с большим количеством пользователей. Как и любой ИТ-продукт, он выступает как основной или вспомогательный инструмент для бизнеса, который должен решать конкретные задачи. Как правило, речь идет про автоматизацию процессов. HighLoad оправдана там, где большое количество пользователей одновременно выполняют те или иные операции в системе. Такие решения, как правило, используют крупные компании типа Avito, Yandex Market, VK и других.
Рис.1. Автоматизация – наше всё
Если говорить о HighLoad-системах, в голову приходит мысль о распределенной архитектуре. У машин, на которых производятся вычисления, как и у человека, ресурсы ограничены. Поэтому высоконагруженный продукт требуется распределить на несколько машин.
Рис.2. Распределение ресурсов для реализации продукта
Далее поделюсь, как функциональные требования могут повлиять на архитектуру, а также расскажу про управление требованиями.
Спойлер: Как любая сложная структура не может обойтись без описания её функциональности, HighLoad-система нуждается в документации и описании предметной области.
Почему важно тщательно прорабатывать требования к архитектуре до реализации и каких последствий это поможет избежать
Процесс формирования основных требований к архитектуре будущего продукта очень важен, поскольку включает в себя:
- Выявление требований к функциональности системы
- Определение интереса и ценности для конечного пользователя
- Определение основных компонентов системы и их взаимосвязей
- Определение требуемых ресурсов для развертывания и поддержки
- Исследование возможности использования готовых решений или облачных решений с целью оптимизации затрат на поддержание будущей инфраструктуры
В основе любого продукта – люди. Их опыт, знания и интерес влияют на архитектуру продукта. Большинство проектных команд формируется из разных специалистов, которые должны стремиться к одной цели и делать один продукт. Требования помогают задать команде проекта единый вектор направления. За структурное документирование требований отвечает аналитик.
Держим в голове подход Domain Driven Design, который подразумевает необходимость погружения в предметную область и наличие итеративного процесса.
С помощью тщательно проработанных требований можно отсечь лишние коммуникации, зафиксировать все аспекты будущего продукта и при необходимости отследить историю и причины изменений требований в дальнейшем
Что дает проработка требований к архитектуре?
Во-первых, понятные цели продукта и его ограничения. Конкретизация поставленных целей помогает:
- сформировать единое завершенное представление продукта
- верно расставить приоритеты и определить контекст продукта, его первой версии
- обозначить границы продукта.
Тем самым, команда сэкономит бюджет и ресурсы проекта.
Во-вторых, определение структуры и взаимосвязей компонентов будущей системы. Это позволит сформировать верхнеуровневое представление о продукте, отразить необходимые целевые взаимосвязи между компонентами, уменьшить количество лишних связей и зависимостей между компонентами, сделать навигацию по компонентам более простой, а значит, быстрее проектировать и вносить изменения в продукт.
В-третьих, управление изменениями. По мере роста продукт становится сложнее. Связанность компонентов системы может усиливаться. Поэтому отражение всех изменений и принятых решений может быть полезно при возврате к тому или иному участку в будущем для рефакторинга, доработок, копирования функциональности в другой компонент и миграции на другую архитектуру....