Реестр архитектурных решений

---
id: ADR-0042
title: Краткое название принятого решения
status: proposed
date-created: 2026-08-01
date-decided:
owners:
  - team-or-person
decision-makers: []
consulted: []
informed: []

scope:
  systems: []
  components: []
  repositories: []

tags: []
supersedes: []
superseded-by: []
related-adrs: []
related-rfcs: []
related-design-docs: []
related-issues: []
related-code: []
review-or-revisit:
---

# ADR-0042: Краткое название принятого решения

## Контекст и проблема

Какую проблему решаем?
Какие факты, ограничения и противоречивые силы действуют?
Что находится вне области решения?

## Драйверы решения

- Какое качество или ограничение наиболее важно?
- Какие условия обязательны?
- Какие критерии позволяют сравнить варианты?

## Рассмотренные варианты

1. Вариант A.
2. Вариант B.
3. Ничего не менять.

## Решение

Мы будем ...

Почему выбранный вариант лучше соответствует драйверам?

## Последствия

Положительные:
- ...

Отрицательные:
- ...

Операционные:
- ...

## Проверка соблюдения

Как убедиться, что реализация соответствует решению?
Какие тесты, метрики, ревью или архитектурные правила это проверяют?

## Условия пересмотра

При каком изменении нагрузки, требований, стоимости, команды
или регуляторных ограничений решение нужно пересмотреть?

## Дополнительные материалы

Ссылки на RFC, design docs, задачи, код, инциденты и связанные ADR.

---
id: ADR-0012
title: Использовать реляционную БД как основное хранилище сервиса заказов
status: accepted
date-created: 2026-08-03
date-decided: 2026-08-07
owners: [orders-team]
scope:
  systems: [order-management]
  components: [order-service]
tags: [database, consistency, orders]
related-issues: [ORD-418]
review-or-revisit: 2027-02-01
---

# ADR-0012: Использовать реляционную БД как основное хранилище сервиса заказов

## Контекст и проблема

Сервис должен хранить заказ, позиции, платежное состояние и историю
переходов. В рамках одного заказа нужно атомарно менять связанные
сущности и однозначно восстанавливать состояние. Основные запросы
идут по заказу, клиенту или временному диапазону.

Решение не определяет аналитическое хранилище и полнотекстовый поиск.

## Драйверы решения

- Транзакционная целостность.
- Понятная модель миграций схемы.
- Операционный опыт команды.
- Воспроизводимые интеграционные тесты.
- Предсказуемое резервное копирование.

## Рассмотренные варианты

1. Реляционная БД как system of record.
2. Документная БД как system of record.
3. Event store как единственный источник состояния.

## Решение

Мы будем использовать управляемую реляционную БД как основное
хранилище order-service. События для других систем публикуются
через transactional outbox.

## Последствия

Положительные:
- Инварианты заказа можно обеспечивать в транзакции.
- Команда использует знакомые миграции и диагностику.

Отрицательные:
- Online-миграции крупных таблиц требуют отдельной дисциплины.
- Сложную аналитику нельзя переносить на operational DB.

## Проверка соблюдения

- Интеграционные тесты проверяют атомарность изменения заказа и outbox.
- Code review проверяет отсутствие dual writes.
- Архитектурный тест запрещает запись в таблицы order-service из других сервисов.

## Условия пересмотра

Пересмотреть, если профиль нагрузки потребует разделения данных
или транзакционные границы изменятся.

---
id: ADR-0021
title: Изолировать интеграцию с партнерской системой через асинхронный адаптер
status: accepted
date-created: 2026-08-10
date-decided: 2026-08-14
owners: [integration-team]
scope:
  systems: [partner-fulfilment-integration]
tags: [integration, resilience, idempotency]
related-rfcs: [RFC-007]
review-or-revisit: 2026-11-01
---

# ADR-0021: Изолировать интеграцию с партнерской системой через асинхронный адаптер

## Контекст и проблема

После подтверждения заказа нужно передать партнеру заявку на выполнение.
Внешний API имеет собственное окно доступности, timeout-ответы не всегда
однозначны, а модель состояний партнера отличается от нашей.

Пользовательский checkout не должен зависеть от мгновенной доступности партнера.

## Драйверы решения

- Не терять подтвержденные заявки.
- Поддерживать идемпотентные повторы.
- Видеть состояние интеграции.
- Не протаскивать внешнюю модель данных в checkout.

## Рассмотренные варианты

1. Синхронный вызов партнера из checkout.
2. Асинхронная очередь и выделенный adapter component.
3. Периодическая пакетная выгрузка.

## Решение

Мы будем записывать локальное намерение интеграции в рамках транзакции
заказа и асинхронно передавать его adapter component. Adapter назначает
idempotency key, преобразует модель данных и управляет retry-политикой.

Checkout возвращает результат после сохранения заказа, не ожидая
внешнего подтверждения.

## Последствия

Положительные:
- Недоступность партнера не блокирует оформление заказа.
- Внешний контракт изолирован в одном компоненте.

Отрицательные:
- Возникает eventual consistency.
- Нужны reconciliation job, dead-letter queue и интерфейс поддержки.

## Проверка соблюдения

- Запрещены прямые вызовы partner API из checkout package.
- Contract tests проверяют преобразование данных.
- Метрики отслеживают возраст очереди, повторы и DLQ.

## Условия пересмотра

Пересмотреть, если партнер даст гарантированную transactional messaging-интеграцию
или продукт потребует синхронного подтверждения.

---
id: ADR-0030
title: Развивать продукт как модульный монолит с явными доменными границами
status: accepted
date-created: 2026-08-17
date-decided: 2026-08-21
owners: [platform-team]
scope:
  systems: [core-product]
tags: [architecture-style, modularity, deployment]
review-or-revisit: 2027-02-01
---

# ADR-0030: Развивать продукт как модульный монолит с явными доменными границами

## Контекст и проблема

Продукт быстро меняется, доменные границы еще уточняются, а несколько
команд регулярно меняют одни и те же пользовательские сценарии.
Платформа для эксплуатации большого числа сервисов пока не создана.

При этом нужно предотвратить рост неструктурированного монолита.

## Драйверы решения

- Скорость изменения сквозных сценариев.
- Низкая операционная сложность.
- Явные границы ownership.
- Возможность будущего выделения модулей.
- Единый deployment для транзакционных изменений.

## Рассмотренные варианты

1. Микросервисы по предполагаемым доменным областям.
2. Неструктурированный монолит.
3. Модульный монолит с контролируемыми зависимостями.

## Решение

Мы будем использовать единый deployable, разделенный на доменные модули.
Каждый модуль имеет публичный application interface и не обращается
к внутренним пакетам или таблицам другого модуля. Выделение модуля
в отдельный сервис требует нового ADR.

## Последствия

Положительные:
- Сквозные изменения не требуют координации нескольких deployments.
- Границы можно уточнять по мере изучения домена.

Отрицательные:
- Независимое масштабирование ограничено.
- Дисциплину границ нужно обеспечивать тестами и ревью, а не договоренностями.

## Проверка соблюдения

- Architecture tests проверяют допустимые направления зависимостей.
- Модули не импортируют internal packages друг друга.
- Прямой доступ к чужим таблицам запрещен review checklist и тестом.

## Условия пересмотра

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