Архитектура · Средняя
Спроектировать модель ошибок
Определить типы ошибок, формат ответа и правила логирования.
Быстро понять за 2 минуты
Определить типы ошибок, формат ответа и правила логирования. На выходе: формат ошибок документирован.
Контекст
Пункт относится к этапу «Архитектура». Его задача — определить границы решения и избежать случайного усложнения системы. Он нужен до передачи результата разработчикам, QA и команде эксплуатации: иначе команда рискует возвращать 500 на бизнес-ошибки.
Что это дает
Единая модель ошибок упрощает frontend-интеграцию, поддержку и диагностику production-инцидентов. Это помогает связать работу с общей целью: надежная, безопасная и поддерживаемая система. Практический эффект виден, когда формат ошибок документирован.
Как выполнить
- Разделите validation, auth, business и system errors.
- Опишите формат error response.
- Не раскрывайте чувствительные детали во внешнем ответе.
Критерии приемки
- Формат ошибок документирован.
- Коды ошибок стабильны.
- Логи содержат диагностический контекст.
Типичные ошибки
- Возвращать 500 на бизнес-ошибки.
- Показывать stack trace пользователю.
- Делать разные форматы ошибок в разных эндпоинтах.
Инструменты
Рабочий артефакт
Architecture note
Архитектура: документ с выводом, доказательствами, ответственным и следующим действием
Пример для разработки сервиса заказов: специалист начинает с действия «Разделите validation, auth, business и system errors». Результат прикладывают к рабочей задаче и передают следующему участнику. Пункт закрывают не по факту обсуждения, а когда выполнено условие: «Формат ошибок документирован».
- Bounded context
- Dependencies
- Domain entities
- Risk areas
Контроль качества
Карта границ сервиса
Формат ошибок документирован.
После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.
Контракт, ограничения, сценарии отказа, метрики, владельца сервиса и критерии готовности.
Перед отметкой выполнено: Формат ошибок документирован.
Как применять
Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.