mirror of
https://github.com/gromlab-ru/slm-design.git
synced 2026-08-22 07:30:16 +03:00
109 lines
9.1 KiB
Markdown
109 lines
9.1 KiB
Markdown
---
|
||
layout: home
|
||
title: Архитектура фронтенд-приложений
|
||
description: SLM Design помогает командам сохранять понятную структуру и предсказуемо развивать фронтенд-приложения по мере роста продукта.
|
||
|
||
hero:
|
||
name: SLM Design
|
||
text: Архитектура фронтенд-приложений
|
||
tagline: Практичная модель для растущих команд и продуктов. Меньше споров о структуре, безопаснее изменения и понятнее код.
|
||
image:
|
||
src: /logo.svg
|
||
alt: SLM Design
|
||
actions:
|
||
- theme: brand
|
||
text: Узнать, как это работает
|
||
link: /architecture/
|
||
- theme: alt
|
||
text: Посмотреть правила
|
||
link: /rules/registry
|
||
|
||
features:
|
||
- title: Один язык для всей команды
|
||
details: Разработчики одинаково понимают границы, ответственность и место нового кода. Архитектурные решения перестают зависеть от личных предпочтений.
|
||
- title: Предсказуемые изменения
|
||
details: Локальная правка остаётся локальной. Команда может развивать внутреннюю реализацию, не переписывая половину приложения.
|
||
- title: Рост без хаоса
|
||
details: Структура усложняется только вместе с продуктом, а не из-за количества файлов, компонентов или выбранных библиотек.
|
||
- title: Архитектура видна в репозитории
|
||
details: Правила выражены кодом и структурой проекта, поэтому документация не расходится с реальным приложением.
|
||
- title: Независимость от стека
|
||
details: SLM не требует конкретного фреймворка, state manager или способа работы с данными и не ограничивает внутреннюю реализацию.
|
||
- title: Постепенное внедрение
|
||
details: Начните с одного спорного участка и расширяйте модель по мере необходимости, без полной перестройки приложения.
|
||
---
|
||
|
||
## Папки перестают быть архитектурой, когда продукт начинает расти
|
||
|
||
На старте почти любая структура выглядит понятной. Затем появляются десятки компонентов, общие hooks, Providers, stores, глубокие импорты и модули, которые знают друг о друге слишком много. Папки остаются на месте, но границы ответственности исчезают.
|
||
|
||
SLM возвращает архитектуре наблюдаемый смысл:
|
||
|
||
> **Модуль владеет ответственностью. Весь код внутри ближайшей модульной границы реализует её.**
|
||
|
||
Это правило одинаково работает для страницы, доменного сценария, UI-библиотеки, инфраструктурного сервиса и небольшого внутреннего модуля.
|
||
|
||
## Что меняется для команды
|
||
|
||
| Когда границ нет | С SLM Design |
|
||
|---|---|
|
||
| Решение о размещении кода принимается по похожей папке | Сначала определяется ответственность и её владелец |
|
||
| Компоненты и services становятся скрытыми архитектурными центрами | Любой внутренний механизм остаётся реализацией ближайшего модуля |
|
||
| Потребители импортируют удобный внутренний файл | Чужой модуль доступен только через публичный фасет |
|
||
| Циклы обнаруживаются во время большого рефакторинга | Модульный граф можно проверять lint-инструментами |
|
||
| Новые уровни создаются из-за размера каталога | Вложенный модуль появляется только для самостоятельной подответственности |
|
||
|
||
Результат: меньше случайной связанности, меньше споров о папках и предсказуемый радиус каждого изменения.
|
||
|
||
## Не ещё один шаблон директорий
|
||
|
||
SLM не диктует, какие библиотеки, state managers или framework-механизмы использовать. Внутри модуля могут находиться компоненты, Providers, Guards, hooks, stores, services, utilities и сторонние SDK.
|
||
|
||
Архитектура отвечает на другие вопросы:
|
||
|
||
1. За какой результат отвечает этот код?
|
||
2. Какой модуль владеет его контрактом и состоянием?
|
||
3. Что действительно нужно внешним потребителям?
|
||
4. Какие зависимости допустимы и не создают ли они цикл?
|
||
5. Где заканчивается область жизни ресурсов?
|
||
6. Какой доменный контракт и какие ошибки определены до подключения источника данных?
|
||
|
||
Файловая структура появляется после ответов, а не заменяет их.
|
||
|
||
## От одного файла до дерева владельцев
|
||
|
||
Модуль может начинаться с одного главного файла и расти без смены архитектурной сущности:
|
||
|
||
```text
|
||
checkout/
|
||
├── index.ts # Публичный контракт
|
||
├── checkout.tsx # Главная реализация
|
||
├── components/ # Внутренний код checkout
|
||
├── hooks/
|
||
├── services/
|
||
└── modules/
|
||
└── form-session/ # Самостоятельная подответственность
|
||
├── index.ts
|
||
├── form-session.provider.tsx
|
||
└── hooks/
|
||
```
|
||
|
||
Размер, количество файлов и framework-роли не создают владельца. Только отдельно сформулированная ответственность получает модульную границу.
|
||
|
||
## Правила, которые можно проверить
|
||
|
||
SLM разделяет смысловые решения и структурные инварианты:
|
||
|
||
- ответственность, владелец и минимальный публичный контракт проверяются на архитектурном ревью;
|
||
- направления между слоями, глубокие импорты, публичные фасеты и модульные циклы проверяются автоматически;
|
||
- каждый rule имеет стабильный код и одно место нормативной формулировки;
|
||
- framework-компоненты не образуют бесконечную файловую рекурсию, а новые уровни появляются только через вложенные модули.
|
||
|
||
Вы получаете не абстрактный набор рекомендаций, а модель, которую можно обсуждать одинаковыми терминами, видеть в репозитории и постепенно автоматизировать.
|
||
|
||
## Начните с одной ответственности
|
||
|
||
Не нужно переписывать приложение целиком. Выберите один спорный участок, сформулируйте его ответственность, назначьте владельца и закройте внутреннюю реализацию публичным API. Этого достаточно, чтобы увидеть разницу между папкой и архитектурной границей.
|
||
|
||
[Спроектировать первый модуль](./architecture/modules.md) · [Спроектировать домен](./architecture/domains.md) · [Разобрать зависимости](./architecture/dependencies.md) · [Проверить существующую структуру](./reference/validation.md)
|