Старт: превращаем бизнес-требование в набор проверяемых утверждений

Сначала важно сделать требование измеримым и проверяемым, иначе архитектуру будет невозможно “принять”.

1) Уточнение требований (что именно нужно сделать)

Не начинайте с технологий — начните с вопросов к бизнесу:

• Какие пользовательские сценарии (1-3 основных)?

• Что считается успехом: метрика, SLA, ограничения?

• Какие данные нужны и откуда они берутся?

• Какие ошибки допустимы (например, можно ли вернуть “нет данных” вместо падения)?

Определение: SLA — обещание по качеству сервиса (например, время ответа и доступность).

2) Разведка по интеграциям со смежными командами

Цель — понять, какие внешние зависимости определяют ваш дизайн.

• Контракты: REST/gRPC/события, форматы, версии

• Ограничения: rate limit, квоты, размер payload

• Надёжность: что будет при таймаутах/ошибках/частичной доступности

• Семантика данных: кто источник истины, как обновления приходят

3) Фиксация границ сервиса и контрактов

Появляется первая “скелетная” архитектура:

• Зона ответственности сервиса (что внутри, что вне)

• API сервиса:

  • основные операции

  • коды ошибок и их смысл

  • идемпотентность для повторных запросов

Определение: Idempotency — повторный одинаковый запрос даёт тот же результат и не ломает состояние.

Пример: идемпотентный ключ в запросе (идея, не полный протокол):

type CreateReq struct {
	IdempotencyKey string `json:"idempotency_key"`
	// payload...
}

4) Черновой дизайн данных и потоков

На этом шаге вы выбираете, что хранить и как “течёт” информация:

• Какие сущности нужны (минимально)

• Какие данные транзакционные, какие производные (их лучше предрасчитывать)

• Как обновления будут приходить: синхронно (API) или асинхронно (события)

5) Риски и план поставки

Параллельно с архитектурой фиксируются риски и способы их снижения:

• неизвестная нагрузка → закладываем лимиты, профилирование, нагрузочные тесты

• нестабильные зависимости → таймауты, ретраи с ограничением, деградация

• неоднозначные данные → контракт источника истины и правила конфликтов

План поставки:

1. MVP: минимальный сценарий end-to-end

2. Наблюдаемость + алерты (до выхода на прод)

3. Расширение функционала и оптимизации по метрикам

Вывод

Когда нет готовой архитектуры, вы “строите её от требований”: уточняете сценарии и SLA, изучаете зависимости и их ограничения, фиксируете границы и контракты, затем делаете минимальный дизайн данных и реалистичный план инкрементальной поставки.