Назад

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

Спроектировать модель ошибок

Определить типы ошибок, формат ответа и правила логирования.

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

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

Определить типы ошибок, формат ответа и правила логирования.

Главная пользаЕдиная модель ошибок упрощает frontend-интеграцию, поддержку и диагностику production-инцидентов.
Первое действиеРазделите validation, auth, business и system errors.
Готово, когдаФормат ошибок документирован.

Контекст

Backend начинается с понимания домена, границ ответственности, контрактов и того, где система должна быть простой, а где масштабируемой.

ЦельЕдиная модель ошибок упрощает frontend-интеграцию, поддержку и диагностику production-инцидентов.
ДействиеРазделите validation, auth, business и system errors.
ПроверкаФормат ошибок документирован.

Что это дает

Единая модель ошибок упрощает frontend-интеграцию, поддержку и диагностику production-инцидентов.

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

  1. Разделите validation, auth, business и system errors.
  2. Опишите формат error response.
  3. Не раскрывайте чувствительные детали во внешнем ответе.

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

  • Формат ошибок документирован.
  • Коды ошибок стабильны.
  • Логи содержат диагностический контекст.

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

  • Возвращать 500 на бизнес-ошибки.
  • Показывать stack trace пользователю.
  • Делать разные форматы ошибок в разных эндпоинтах.

Инструменты

OpenAPIProblem DetailsLogger

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

Architecture note

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

Схема ответственности сервиса, внешних зависимостей, доменных сущностей и основных потоков данных.

  • Bounded context
  • Dependencies
  • Domain entities
  • Risk areas

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

Артефакт

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

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

Формат ошибок документирован.

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

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

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

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

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

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

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

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

Прочитайте материал, прослушайте аудио и проверьте понимание по коротким вопросам. Ответ раскрывается после попытки сформулировать его самостоятельно.

1. Какую основную пользу должен дать этот пункт?
2. Какой первый практический шаг нужно выполнить?
3. По какому критерию можно понять, что пункт выполнен?