SLM DesignАрхитектура фронтенд-приложений

Папки перестают быть архитектурой, когда продукт начинает расти ​

На старте почти любая структура выглядит понятной. Затем появляются десятки компонентов, общие hooks, Providers, stores, глубокие импорты и модули, которые знают друг о друге слишком много. Папки остаются на месте, но границы ответственности исчезают.

SLM возвращает архитектуре наблюдаемый смысл:

Модуль владеет ответственностью. Весь код внутри ближайшей модульной границы реализует её.

Это правило одинаково работает для страницы, доменного сценария, UI-библиотеки, инфраструктурного сервиса и небольшого внутреннего модуля.

Что меняется для команды ​

Результат: меньше случайной связанности, меньше споров о папках и предсказуемый радиус каждого изменения.

Не ещё один шаблон директорий ​

SLM не диктует, какие библиотеки, state managers или framework-механизмы использовать. Внутри модуля могут находиться компоненты, Providers, Guards, hooks, stores, services, utilities и сторонние SDK.

Архитектура отвечает на другие вопросы:

1. За какой результат отвечает этот код?
2. Какой модуль владеет его контрактом и состоянием?
3. Что действительно нужно внешним потребителям?
4. Какие зависимости допустимы и не создают ли они цикл?
5. Где заканчивается область жизни ресурсов?
6. Какой доменный контракт и какие ошибки определены до подключения источника данных?

Файловая структура появляется после ответов, а не заменяет их.

От одного файла до дерева владельцев ​

Модуль может начинаться с одного главного файла и расти без смены архитектурной сущности:

checkout/
├── index.ts                    # Публичный контракт
├── checkout.tsx                # Главная реализация
├── components/                 # Внутренний код checkout
├── hooks/
├── services/
└── modules/
    └── form-session/           # Самостоятельная подответственность
        ├── index.ts
        ├── form-session.provider.tsx
        └── hooks/

Размер, количество файлов и framework-роли не создают владельца. Только отдельно сформулированная ответственность получает модульную границу.

Правила, которые можно проверить ​

SLM разделяет смысловые решения и структурные инварианты:

• ответственность, владелец и минимальный публичный контракт проверяются на архитектурном ревью;
• направления между слоями, глубокие импорты, публичные фасеты и модульные циклы проверяются автоматически;
• каждый rule имеет стабильный код и одно место нормативной формулировки;
• framework-компоненты не образуют бесконечную файловую рекурсию, а новые уровни появляются только через вложенные модули.

Вы получаете не абстрактный набор рекомендаций, а модель, которую можно обсуждать одинаковыми терминами, видеть в репозитории и постепенно автоматизировать.

Начните с одной ответственности ​

Не нужно переписывать приложение целиком. Выберите один спорный участок, сформулируйте его ответственность, назначьте владельца и закройте внутреннюю реализацию публичным API. Этого достаточно, чтобы увидеть разницу между папкой и архитектурной границей.

Спроектировать первый модуль · Спроектировать домен · Разобрать зависимости · Проверить существующую структуру