Архитектура · Средняя
Зафиксировать архитектурное решение
Описать важный технический выбор в ADR: контекст, варианты, решение и последствия.
Быстро понять за 2 минуты
Описать важный технический выбор в ADR: контекст, варианты, решение и последствия.
Контекст
Backend начинается с понимания домена, границ ответственности, контрактов и того, где система должна быть простой, а где масштабируемой.
Что это дает
ADR сохраняет инженерный контекст и помогает будущей команде понимать, почему выбран именно этот путь.
Как выполнить
- Опишите проблему и ограничения.
- Сравните 2-3 варианта.
- Зафиксируйте выбранное решение и последствия.
Критерии приемки
- ADR опубликован.
- Решение связано с задачей.
- Последствия и trade-off описаны.
Типичные ошибки
- Писать ADR задним числом без альтернатив.
- Фиксировать мелочи как архитектурные решения.
- Не обновлять статус ADR.
Инструменты
Рабочий артефакт
Architecture note
Карта границ сервиса
Схема ответственности сервиса, внешних зависимостей, доменных сущностей и основных потоков данных.
- Bounded context
- Dependencies
- Domain entities
- Risk areas
Контроль качества
Карта границ сервиса
ADR опубликован.
После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.
Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.
Перед отметкой выполнено: ADR опубликован.
Как применять
Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.
Режим обучения
Прочитайте материал, прослушайте аудио и проверьте понимание по коротким вопросам. Ответ раскрывается после попытки сформулировать его самостоятельно.