Команда /dr-design — архитектура решается до кода
Как /dr-design прорабатывает три и более вариантов для каждого компонента дизайна, оценивает компромиссы, фиксирует решение и документирует обоснование — всё это до начала реализации.
Одни задачи реализации достаточно прямолинейны, чтобы план стал достаточным руководством. Другие предполагают решения, последствия которых распространяются на множество файлов, систем или будущих изменений. Для них принятие подхода без намеренной проработки — самый распространённый источник архитектурного долга. Команда /dr-design создаёт структурированное пространство для такой проработки.
Команда предназначена для задач уровней 3 и 4 — тех, где сложность требует большего, чем просто план, но где фаза дизайна отделена от фазы требований. Она запускается после /dr-plan и до /dr-do, а её результат — один или несколько creative-документов, хранящихся в datarim/creative/.
Что она делает
Первый шаг — классификация каждого компонента, требующего дизайн-решения, по одному из четырёх типов: UI/UX-дизайн, архитектурный дизайн, дизайн модели данных или дизайн алгоритма. Тип определяет, какие активности применяются: дизайн модели данных фокусируется на связях между сущностями и оптимизации запросов; архитектурный дизайн — на структуре компонентов и системной интеграции.
Для каждого компонента команда выполняет творческую фазу: чётко определить задачу, проработать минимум три отличных варианта, проанализировать компромиссы каждого, принять решение с задокументированным обоснованием и написать план реализации для выбранного варианта. Там, где структура выигрывает от визуализации, добавляются диаграммы в нотации Mermaid.
Для задач уровней 3 и 4 после анализа отдельных компонентов запускается consilium-проход. Он собирает панель из релевантных агентских перспектив — безопасности, производительности, тестируемости, поддерживаемости — и проводит их через структурированную дискуссию. Панель сходится к рекомендации, а конфликты разрешаются явным приоритетным списком. Результат включает таблицу режимов отказов: что произойдёт, если выбранный подход не сработает, и как этот отказ проявится.
Один конкретный пример
Задача спроектировать модель данных для мультитенантной системы биллинга создаёт creative-документ с тремя вариантами схемы: общая таблица с колонкой tenant, отдельные таблицы на каждого тенанта и гибрид из общих справочных таблиц и тенант-специфичных транзакционных таблиц. Анализ компромиссов показывает, что гибрид лучше работает при ожидаемом количестве тенантов, но вносит сложность миграции. Панель consilium поднимает вопрос безопасности: утечка данных между тенантами в общих справочниках. Финальное решение выбирает гибрид с явной политикой row-level security на общих таблицах, а план реализации включает скрипт миграции и V-AC, проверяющий отсутствие утечки данных между тенантами.
Место в пайплайне
Дизайн-документы, созданные здесь, читает /dr-qa Layer 2 (соответствие дизайну) после реализации. Этот слой проверяет, были ли задокументированные архитектурные решения действительно соблюдены в коде, и помечает любые отклонения для оценки. Отклонение не является автоматически провалом — иногда реализация открывает лучший путь — но должно быть задокументировано, чтобы выбор можно было проверить.
Контрольный список перехода перед переходом к /dr-do требует, чтобы у каждого компонента была чётко определена задача, проанализировано минимум три варианта, зафиксировано решение и написан план реализации. Пропуск любого из этих пунктов в сложной задаче — именно тот тип срезания углов, который проявляется как трудно объяснимый баг через полгода.
Как дизайн вписывается в общий рабочий процесс — в посте что такое Datarim; что происходит дальше — в описании команды /dr-do, которая реализует то, что решил дизайн.