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