Этот документ содержит общие вопросы и шаги, которые полезно пройти при проектировании системы на интервью или архитектурной сессии.
1. Понять задачу и её границы
Перед обсуждением архитектуры нужно понять, для кого и зачем создаётся система.
- Определить заинтересованные стороны и их приоритеты. При необходимости составить RACI-матрицу.
- Понять бизнес-цели и причины создания проекта.
- Определить конечных пользователей и основные способы использования системы.
- Собрать функциональные требования.
- Определить внешние зависимости.
- Предложить дополнительные полезные функции.
- Явно исключить требования и сценарии, которые не входят в scope.
2. Уточнить приоритеты и итерации
Нужно определить, что именно требуется реализовать и в каком порядке.
- Что обязательно должно войти в первую итерацию?
- Что можно отложить на следующие итерации?
- Какие функции имеют наивысший приоритет?
- Как выглядит минимально полезная версия системы?
- Какие сценарии пока осознанно не поддерживаем?
- Какие ограничения первой итерации допустимы?
- По каким критериям поймём, что первая итерация успешна?
Результатом должен стать явно зафиксированный scope первой итерации и примерное разбиение дальнейшего развития системы на этапы:
Все требования
↓
Приоритеты
↓
Scope первой итерации / MVP
↓
Допустимые ограничения
↓
Следующие итерации
3. Определить ограничения и нефункциональные требования
Нужно зафиксировать ожидаемый масштаб и требования к качеству системы.
- Количество пользователей сейчас и ожидаемый рост через год и несколько лет.
- Среднее и пиковое количество запросов в секунду или месяц.
- Соотношение операций чтения и записи.
- Требования ко времени ответа.
- Текущий и прогнозируемый объём базы данных.
- Текущий и прогнозируемый объём файлового или объектного хранилища.
- Требования к безопасности и приватности.
- Допустимое время простоя, SLA, RTO и RPO.
- Когда система или первая версия должна быть запущена? Это жёсткий deadline или желательный срок?
- Есть ли промежуточные этапы и обязательные даты?
- Каковы размер, опыт и доступность команды?
- Каковы ограничения по бюджету разработки и эксплуатации?
- Есть ли обязательный или запрещённый технологический стек?
- Какие технологии уже используются и поддерживаются внутри компании?
- Ограничения заказчика: legacy-системы, проприетарное ПО, регуляторные требования и существующая инфраструктура.
4. Выделить архитектурно значимые требования
Из функциональных и нефункциональных требований нужно выделить те, которые сильнее всего влияют на архитектуру — Architecture Significant Requirements (ASR).
Например, глобальная география пользователей, строгая консистентность, высокая доступность, работа с персональными данными или необходимость обработать резкие пики нагрузки могут существенно изменить решение.
5. Сделать высокоуровневый дизайн
- Выбрать архитектурные представления с учётом аудитории: C4, 4+1 или другой подходящий формат.
- Выбрать архитектурный стиль: монолит, модульный монолит, микросервисы, event-driven architecture и так далее.
- Выбрать между облачной, on-premise или гибридной инфраструктурой.
- Определить основные компоненты системы и их зоны ответственности.
- Выбрать конкретные технологии для компонентов, исходя из требований, ограничений, компетенций команды и стоимости эксплуатации.
- Объяснить ключевые технологические решения и рассмотренные альтернативы.
- Определить внешние и внутренние API, а также способы взаимодействия компонентов.
- Продумать аутентификацию, авторизацию и защиту персональных данных.
- Определить необходимые правила безопасности и протоколы.
- Продумать инфраструктуру: балансировку нагрузки, очереди и брокеры сообщений.
- Набросать ключевые алгоритмы, если они определяют работу системы.
- Найти возможные узкие места и способы их устранения.
- Выбрать типы хранилищ: SQL, NoSQL, object storage, search engine и другие.
- Определить, какие данные кешировать и как кеш повлияет на производительность, безопасность и доступность.
- Продумать мониторинг, логирование, трассировку, аналитику и автоматическое восстановление после сбоев.
- Разделить публичные и закрытые части системы.
6. Сверить решение с требованиями
В конце нужно проверить, что предложенная архитектура:
- покрывает основные пользовательские сценарии первой итерации;
- удовлетворяет архитектурно значимым требованиям;
- укладывается в обозначенные сроки и ограничения;
- допускает развитие в следующих итерациях;
- содержит явно проговорённые компромиссы и риски.
