Назад

Архитектура · Средняя

Зафиксировать архитектурное решение

Описать важный технический выбор в ADR: контекст, варианты, решение и последствия.

Архитектура: визуальный контекст этапа
Аудиопересказ пунктаПолная версия материала для прослушивания
Прослушано 0%
Скачать

Быстро понять за 2 минуты

Описать важный технический выбор в ADR: контекст, варианты, решение и последствия. На выходе: aDR опубликован.

Главная пользаADR сохраняет инженерный контекст и помогает будущей команде понимать, почему выбран именно этот путь.
Первое действиеОпишите проблему и ограничения.
Готово, когдаADR опубликован.

Контекст

Пункт относится к этапу «Архитектура». Его задача — определить границы решения и избежать случайного усложнения системы. Он нужен до передачи результата разработчикам, QA и команде эксплуатации: иначе команда рискует писать ADR задним числом без альтернатив.

ЦельADR сохраняет инженерный контекст и помогает будущей команде понимать, почему выбран именно этот путь.
ДействиеОпишите проблему и ограничения.
ПроверкаADR опубликован.

Что это дает

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

Как выполнить

  1. Опишите проблему и ограничения.
  2. Сравните 2-3 варианта.
  3. Зафиксируйте выбранное решение и последствия.

Критерии приемки

  • ADR опубликован.
  • Решение связано с задачей.
  • Последствия и trade-off описаны.

Типичные ошибки

  • Писать ADR задним числом без альтернатив.
  • Фиксировать мелочи как архитектурные решения.
  • Не обновлять статус ADR.

Инструменты

ADRMarkdownConfluenceAPI contractлогированиемониторингрепозиторийсистема мониторинга

Рабочий артефакт

Architecture note

Архитектура: документ с выводом, доказательствами, ответственным и следующим действием

Пример для разработки сервиса заказов: специалист начинает с действия «Опишите проблему и ограничения». Результат прикладывают к рабочей задаче и передают следующему участнику. Пункт закрывают не по факту обсуждения, а когда выполнено условие: «ADR опубликован».

  • Bounded context
  • Dependencies
  • Domain entities
  • Risk areas

Контроль качества

Артефакт

Карта границ сервиса

Метрика проверки

ADR опубликован.

Когда пересматривать

После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.

Что передать дальше

Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.

Перед отметкой выполнено: ADR опубликован.

Как применять

Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.

Режим обучения

Тест по теме

Проверка понимания

Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.

0/4ответов выбрано
1. Какой главный результат должен дать пункт «Зафиксировать архитектурное решение»?
2. С какого действия логично начать выполнение?
3. Как понять, что тема действительно закрыта?
4. Какой ошибки стоит избегать в этой теме?
Материал подготовлен командойAriol.by