Архитектурные решения (ADR)
ADR (Architecture Decision Record) — короткая запись об одном значимом архитектурном решении: в каком контексте оно принято, что именно решили и какие у этого последствия.
Зачем это нужно
Код показывает, как всё устроено, но не почему. Через год (или для нового человека) причина решения теряется — и его либо «улучшают» обратно в то, от чего ушли, либо боятся трогать, не понимая логики. ADR фиксирует причину в момент принятия.
Правила ведения:
- Одно решение — одна запись. Файлы нумеруются по порядку
(
0001-...,0002-...). - Записи не переписывают задним числом. Если решение устарело — заводят
новую запись с другим решением, а старую помечают статусом
superseded(заменено) со ссылкой на новую. Так сохраняется история, а не подменяется. - Статусы:
accepted(действует),superseded(заменено),deprecated(отменено без замены).
Список решений
| № | Решение | Статус |
|---|---|---|
| 0001 | Монолит, не микросервисы | accepted |
| 0002 | docker-compose, не Kubernetes | accepted |
| 0003 | Серверный рендеринг, не SPA | accepted |
| 0004 | Tailwind собирается, не CDN | accepted |
| 0005 | Заявка пишется в БД первой | accepted |
| 0006 | Языковая политика: английский первый, русский как перевод | accepted |
Шаблон новой записи
# NNNN — Краткое название решения
- **Статус:** accepted
- **Дата:** ГГГГ-ММ-ДД
## Контекст
Какая задача/ограничение заставили принимать решение.
## Решение
Что именно решили (одним-двумя предложениями).
## Последствия
Что это даёт (плюсы) и чем приходится платить (минусы).