Архитектурный дизайн
Статус документа
Черновик / На ревью / Одобрен / В разработке / В архиве
Связанные задачи / эпики
Системные требования
(опционально)
Автор(ы)
Ревьюверы
Ревью техлида направления обязательно в задачах, где меняется архитектура
Статус ревью
Approve Frontend
Approve Backend
Постарайтесь сделать документ не перегруженным лишними деталями. Визуализация > текст, но для сложных диаграмм стоит добавлять текстовое описание. Документ пишется на выпускаемую end-to-end функциональность и не зависит от типа задачи.
Контекст
Какой бизнес-проблемой или фичей вызвано изменение? Как это связано с текущей архитектурой?
Область реализации
Что входит в решение, а что исключается? Например:
Входит:
Расчёт подписок с новыми тарифами
Хранение истории расчётов
Не входит:
Отображение расчётов в UI
Изменения в биллинге
Обоснование и связь с требованиями
Какие бизнес и системные требования покрываются этим дизайном.
Архитектура
#Диаграмма компонентов
Можно по уровням: система / контейнер / компонент.
Компоненты и взаимодействие
Компонент
Ответственность
Владелец
Команда A
Команда B
Внешняя система
Изменения в базе данных
Таблица
Тип
Изменения
Интерфейсы и события
Тип
Интерфейс / Событие
Формат
Auth
HTTP API
POST <URL>
JSON
Bearer
Event
subscription.recalculated.v1
avro
—
Поведение
Основные сценарии (в текстовом виде или как диаграмма последовательностей). Например:
Админ запускает пересчёт вручную
Сервис собирает все активные подписки
Для каждой подписки создаётся джоба расчёта
Джобы обрабатываются в воркере
После расчёта публикуется событие
subscription.recalculated
Допускаются ссылки на системные требования.
Ошибки и отказоустойчивость
Что происходит при сбоях:
Как ретраится?
Есть ли дедупликация?
Где хранятся неуспешные расчёты?
Какие алерты?
Тестирование и мониторинг
👉🏻 Стратегия контроля качества
Что
Пример
Тесты
Интеграционный тест на пересчёт тарифа Standard
Метрики
subscription.calculation.duration
Алерты
Ошибки >5% за 10 минут по calculation.failure.rate
Прочие нефункциональные требования
👉🏻 Нефункциональные требования
Допускается ссылка на системные требования.
План внедрения
Разбей внедрение по этапам, если оно сложное или нужно выкатывать по частям. Укажи зависимые команды, сервисы, окружения.
Альтернативы и отклонённые варианты
Какие подходы рассматривались и почему были отклонены?
По возможности указывать как альтернативные решения влияют на сроки.
Пример:
С рефакторингом задача затянется – может занять в районе 3х месяцев
Без рефакторинга – 1 месяц, но будут жалобы от пользователей на медленную работу фильтров (1-2 минуты)
Риски и меры
Что может пойти не так? Как можно минимизировать ущерб?
Последнее обновление