Проектные решения и ADR
Проектное решение появляется там, где возможны альтернативы. Если концептуальная модель говорит, что у заказа есть история статусов, технически её можно реализовать по-разному: хранить только текущий статус, хранить журнал изменений в отдельной таблице, публиковать события, использовать внешний сервис аудита. Каждый вариант имеет последствия для данных, производительности, сопровождения и проверки.
Без фиксации решений модель выглядит как набор фактов, хотя на самом деле многие элементы являются результатом выбора. Почему уведомления вынесены в отдельный компонент? Почему используется тонкий клиент? Почему история изменений хранится отдельно? Почему внешний сервис закрыт адаптером? Если ответ нигде не записан, через некоторое время решение начинает казаться случайным.
Простой шаблон ADR:
| Раздел | Содержание |
|---|---|
| Контекст | какая проблема решается и какие условия важны |
| Решение | какой вариант выбран |
| Альтернативы | что ещё рассматривалось |
| Последствия | что стало проще, что сложнее, какие риски появились |
Мини-пример 1: уведомления.
| Раздел | Пример |
|---|---|
| Контекст | система должна отправлять уведомления студентам и преподавателям через разные каналы |
| Решение | выделить компонент уведомлений и интерфейс отправки |
| Альтернативы | отправлять уведомления напрямую из сервисов приложения |
| Последствия | проще заменить канал отправки, но появляется отдельная зависимость |
Мини-пример 2: история статусов.
| Раздел | Пример |
|---|---|
| Контекст | нужно видеть, кто и когда менял состояние заявки |
| Решение | хранить отдельный журнал изменений статуса |
| Альтернативы | хранить только текущий статус в заявке |
| Последствия | появляется аудит, но усложняется модель данных |
Мини-пример 3: интеграция с внешней системой.
| Раздел | Пример |
|---|---|
| Контекст | авторизация должна выполняться через университетскую систему единого входа |
| Решение | обращаться к ней через адаптер авторизации |
| Альтернативы | встроить вызовы внешнего API напрямую в сервисы приложения |
| Последствия | проще заменить способ авторизации, но нужно поддерживать дополнительный слой |
Проектные решения связывают концептуальную и техническую модель. Если решено вынести отправку уведомлений во внешний сервис, в технической модели должен появиться gateway или adapter, а в системной архитектуре — внешняя система или компонент. Если решено хранить историю изменений, это должно отразиться в архитектуре данных.
Для учебного проекта ADR не должна быть большой. Достаточно нескольких абзацев или небольшой таблицы, чтобы показать осознанность решения и его влияние на последующие материалы.
ADR особенно полезна для решений, которые нельзя вывести автоматически из требований. Требование может сказать, что уведомление должно быть отправлено, но не говорит, будет ли это отдельный компонент, внешний сервис или прямая отправка из приложения. Именно здесь появляется проектное решение. Оно не обязано быть идеальным навсегда, но должно иметь понятную причину.