Архитектурные решения (ADR)
Зачем корпоративная архитектура: согласованность решений в масштабе предприятия, а не «ещё один комитет».
Архитектурное решение — это выбор, который дорого менять: граница сервиса, модель согласованности, брокер, отказ от общей БД. Его нужно фиксировать так, чтобы через год можно было понять не только «что», но и «почему не иначе».
Короткий ADR обычно содержит контекст, рассматриваемые варианты, решение, следствия и статус (принято / устарело / заменено). Объём — страница, не политика. Ссылки на виды, паттерны и выбранный стек обязательны, иначе решение висит в воздухе.
Пишите ADR в момент выбора, а не постфактум «для аудита». Поздняя рационализация вычищает отвергнутые варианты — а именно они нужны следующей команде.
Не каждый merge требует ADR. Нужен порог: затрагивает качества из предыдущего шага, меняет границу контекста или создаёт операционный риск. Мелочи остаются в задаче.
Связка с каталогом: паттерн и технология — материал решения, ADR — его каноническая запись. Ищите CQRS в каталоге; ищите «почему CQRS здесь» в реестре решений.