Модульная архитектура для
DMA говорит людям и агентам, где живёт фронтенд-код, и проверяет границы через линтер, CLI и CI.
Agent
Изучаю skill derived-modular
layers · imports · public
+3 −1 features/checkout/public/api.ts
$npx @derived-modular/cli check .
12 модулей проверено
1 сигнал · stage-growth · checkout
- Install
- dma check
- Deploy
Четыре границы в src/
Без components, utils и прочего «на глаз». Дерево папок задаёт правила, линтер и CI проверяют. Импорты однонаправленные: нижестоящий слой не импортирует вышестоящий.
├─ app/
Точка входа: маршруты и страницы, с чего начинается приложение.
├─ features/
Продуктовые потоки, которые монтирует app: catalog, checkout. Нет входящих рёбер от других модулей; могут импортировать services и shared.
├─ services/
Общие продуктовые сценарии, от которых зависят другие модули. Появляются при promotion — например, catalog и checkout импортируют services/cart.
└─ shared/
Переносимые хелперы и UI: даты, кнопки, HTTP-клиент.
Структура растёт вместе с продуктом
Не нужно проектировать всю структуру заранее. Начните с одного файла и добавляйте папки по мере роста кода.
Файл-модуль
Начинаем с одного файла checkout.tsx. Этот модуль также содержит в себе логику корзины.
Границы проверяются, а не обсуждаются
Ошибиться не даст богатый tooling: линтер, агент и CLI держат одни и те же правила.
Problems
import { getCatalog } from "@/features/catalog/public/api";
ESLint
feature-to-feature
checkout → catalog/public/api.ts
terminal
$ npx @derived-modular/cli check .
feature-to-feature
checkout → catalog/public/api.ts
Один граф импортов. Один результат в редакторе и в CI.
Правила в коде, а не в чате
Установите CLI, создайте структуру папок одной командой и проверяйте архитектуру автоматически — одни и те же правила в редакторе, у агента и при сборке.