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