DMA vs FSD
Честное сравнение Derived Modular Architecture и Feature-Sliced Design.
Feature-Sliced Design (FSD) и DMA решают похожую боль — хаос во фронтенд-архитектуре. Но подход разный: FSD режет по семантике продукта, DMA — по предикатам графа, которые машина может проверить.
Это не «FSD плохой, DMA хороший». Это разные ставки.
Ось сравнения
| FSD | DMA | |
|---|---|---|
| Границы слоёв | Семантика (entity, feature, widget…) | Предикаты (входящие рёбра, direction) |
| Споры на ревью | «Это entity или feature?» | «Есть входящие рёбра? → service» |
| Enforcement | Соглашения, линтеры (разная зрелость) | dma check — полный граф в CI |
| Слоёв модулей | 4–6+ | 2 (features + services) |
| Shared/kernel | Отдельные слои | shared/ с группами |
| Старт проекта | Часто все папки сразу | services/ lazy, shared почти пустой |
| Онбординг | Таксономия помогает новичкам | Меньше слов — больше графа |
Где FSD сильнее
Семантический онбординг. Новичку проще: «всё про пользователя — в entities». DMA не даёт такой шпаргалки — нужно смотреть на зависимости.
Богатая таксономия для больших команд. Когда продукт зрелый и роли разделены (дизайн-система, платформа, фичи), именованные слои FSD — общий язык.
Экосистема. FSD дольше на рынке, больше статей, примеров, инструменты сообщества.
Где DMA сильнее
Машинная проверка. Четыре инварианта (направление, public API, размещение рядом, второе использование) и семь жёстких правил dma check в CI. Спор «можно ли этот импорт» заканчивается код выхода, не часом в Zoom.
Меньше споров о ранге. Два слоя модулей с checkable obligations — не шесть, где граница widget/feature субъективна.
Ленивый рост. Не создаёте пустые services/, entities/, widgets/. Папки появляются, когда граф говорит «пора».
Честные компромиссы. Одна граница остаётся на человеке — services vs shared. Остальное — инструменты.
Можно ли совместить?
Практически — нет смысла наносить FSD-слои поверх DMA-предикатов: получите два конфликтующих набора правил.
Можно заимствовать идеи: именование фич, размещение рядом, публичный API. DMA не запрещает называть папки catalog и checkout — запрещает импортировать feature из feature.
Для кого DMA
- Команды, уставшие от архитектурных споров без объективного критерия
- Проекты, где CI должен ловить циклы и promotion
- Монорепо и долгоживущие кодовые базы, где граф важнее таксономии
Для кого FSD
- Команды, где семантические слои — уже общий язык
- Продукты с жёстким доменным моделированием на старте
- Когда machine enforcement менее критичен, чем онбординг