Проектные решения

Зачем фиксировать проектные решения

Концептуальная модель описывает предметную область. Техническая модель описывает возможную реализацию. Между ними всегда есть проектные решения.

Например, концептуальный класс Order может быть реализован как доменная модель, ORM entity, DTO, набор таблиц, сервисные методы и события. Можно хранить статус заказа как поле, отдельный объект состояния или вычислять его по истории событий. Все эти варианты могут быть допустимыми, но у каждого будут последствия.

Если проектное решение не зафиксировано, через некоторое время становится непонятно:

почему модель устроена именно так;
какие альтернативы рассматривались;
какое ограничение повлияло на выбор;
что может сломаться при изменении решения;
какие диаграммы нужно обновить.

Что считается проектным решением

Проектное решение - это осознанный выбор, который влияет на структуру, поведение или развёртывание системы.

Типичные примеры:

выбрать слоистую архитектуру;
выделить отдельный сервис для уведомлений;
сделать внешний платёжный сервис отдельным компонентом;
хранить историю состояний объекта;
использовать DTO между presentation и application layer;
разделить концептуальный класс на несколько технических классов;
показать интеграцию через gateway или adapter;
разместить базу данных на отдельном узле.

Не каждую мелочь нужно оформлять как отдельное решение. Фиксировать стоит то, что влияет на несколько частей модели или может вызвать спор при дальнейшем проектировании.

Минимальный шаблон ADR

Для краткой фиксации проектных решений часто используют ADR: Architecture Decision Record. В рамках курса достаточно минимального варианта.

Поле	Содержание
Контекст	какая проблема или ограничение привели к решению
Решение	какой вариант выбран
Альтернативы	какие варианты рассматривались
Последствия	что упрощается, что усложняется, какие риски появляются

Пример:

Поле	Содержание
Контекст	система должна отправлять уведомления через разные каналы
Решение	выделить компонент Notification Service и интерфейс отправки
Альтернативы	отправлять уведомления напрямую из application service
Последствия	проще заменить канал отправки, но появляется дополнительная зависимость

Связь с UML-моделью

Проектные решения помогают объяснить, почему техническая модель отличается от концептуальной. Они связывают диаграмму классов, диаграмму пакетов, диаграмму компонентов и диаграмму развёртывания.

Если на диаграмме появился класс, интерфейс, компонент или узел, которого не было в предметной модели, это не ошибка. Но должно быть понятно, какое проектное решение его породило.

Хорошая UML-модель показывает не только то, какие элементы существуют, но и почему они появились именно в таком виде.