update team, test
This commit is contained in:
@@ -2,4 +2,109 @@
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Классическая архитектура
|
||||
# Классическая архитектура
|
||||
Источник: DeepSeek
|
||||
|
||||
Layer-based architecture (архитектура на основе слоёв) — это подход к организации кода, при котором приложение разделяется на несколько логических слоёв, каждый из которых отвечает за определённый аспект функциональности. Этот метод широко используется как во фронтенд-, так и в бэкенд-разработке и помогает создавать структурированные, поддерживаемые и масштабируемые приложения.
|
||||
|
||||
## Основные идеи Layer-based Architecture
|
||||
1. **Разделение ответственности:**
|
||||
- Каждый слой отвечает за определённую часть функциональности (например, отображение данных, управление состоянием, работа с API).
|
||||
- Это упрощает понимание кода и снижает вероятность ошибок.
|
||||
2. **Изоляция слоёв:**
|
||||
- Слои взаимодействуют друг с другом через чётко определённые интерфейсы, что делает их независимыми.
|
||||
- Изменения в одном слое минимально влияют на другие.
|
||||
3. **Повторное использование:**
|
||||
- Логика, вынесенная в отдельные слои, может быть переиспользована в разных частях приложения.
|
||||
|
||||
## Основные слои во фронтенд-разработке
|
||||
1. Presentation Layer (Слой представления):
|
||||
- Отвечает за отображение данных и взаимодействие с пользователем.
|
||||
- Включает компоненты, стили и UI-логику.
|
||||
- Пример: React-компоненты, Vue-компоненты, Angular-шаблоны.
|
||||
2. Application Layer (Слой приложения):
|
||||
- Управляет бизнес-логикой приложения.
|
||||
- Координирует взаимодействие между слоем представления и слоем данных.
|
||||
- Пример: хуки, сервисы, контроллеры.
|
||||
3. Data Layer (Слой данных):
|
||||
- Отвечает за работу с данными: получение, хранение, обновление.
|
||||
- Включает API-запросы, управление состоянием (например, Redux, MobX), локальное хранилище (localStorage, IndexedDB).
|
||||
- Пример: Redux slices, GraphQL-запросы, REST API-клиенты.
|
||||
4. Infrastructure Layer (Инфраструктурный слой):
|
||||
- Включает вспомогательные функции, утилиты и инструменты, которые используются во всех слоях.
|
||||
- Пример: хелперы, утилиты, конфигурация приложения.
|
||||
|
||||
Пример структуры проекта с Layer-based Architecture
|
||||
```
|
||||
src/
|
||||
│
|
||||
├── components/ # Presentation Layer: UI-компоненты
|
||||
│ ├── Button/
|
||||
│ ├── Header/
|
||||
│ └── Footer/
|
||||
│
|
||||
├── pages/ # Presentation Layer: Страницы
|
||||
│ ├── HomePage/
|
||||
│ └── ProfilePage/
|
||||
│
|
||||
├── hooks/ # Application Layer: Хуки для бизнес-логики
|
||||
│ ├── useAuth/
|
||||
│ └── useCart/
|
||||
│
|
||||
├── store/ # Data Layer: Управление состоянием (Redux, Zustand)
|
||||
│ ├── slices/
|
||||
│ │ ├── authSlice.ts
|
||||
│ │ └── cartSlice.ts
|
||||
│ └── index.ts
|
||||
│
|
||||
├── api/ # Data Layer: Работа с API
|
||||
│ ├── authApi.ts
|
||||
│ └── cartApi.ts
|
||||
│
|
||||
├── utils/ # Infrastructure Layer: Утилиты и хелперы
|
||||
│ ├── formatDate.ts
|
||||
│ └── validateForm.ts
|
||||
│
|
||||
└── App.tsx # Основной файл приложения
|
||||
```
|
||||
|
||||
## Преимущества Layer-based Architecture
|
||||
1. **Чёткая структура:**
|
||||
- Код легко понять и поддерживать благодаря разделению на слои.
|
||||
2. **Упрощение тестирования:**
|
||||
- Каждый слой можно тестировать изолированно.
|
||||
3. **Гибкость:**
|
||||
- Слои можно заменять или модифицировать без влияния на другие части приложения.
|
||||
4. **Повторное использование:**
|
||||
- Логика, вынесенная в отдельные слои, может быть переиспользована.
|
||||
|
||||
## Недостатки Layer-based Architecture
|
||||
1. **Избыточность для небольших проектов:**
|
||||
- В маленьких приложениях такая структура может показаться излишне сложной.
|
||||
2. **Зависимость между слоями:**
|
||||
- Если не соблюдать чёткие границы, слои могут стать слишком связанными.
|
||||
3. **Сложность настройки:**
|
||||
- Требуется время и усилия для правильной организации слоёв.
|
||||
|
||||
## Пример взаимодействия слоёв
|
||||
1. **Presentation Layer:**
|
||||
- Компонент CartList отображает список товаров в корзине.
|
||||
2. **Application Layer:**
|
||||
- Хук useCart управляет логикой корзины.
|
||||
3. **Data Layer:**
|
||||
- Redux slice управляет состоянием корзины.
|
||||
4. **Infrastructure Layer:**
|
||||
- Утилита для форматирования цены.
|
||||
|
||||
## Когда использовать Layer-based Architecture
|
||||
- В проектах среднего и крупного размера.
|
||||
- Когда требуется чёткое разделение ответственности.
|
||||
- В командах, где разные разработчики работают над разными аспектами приложения.
|
||||
|
||||
Альтернативные подходы
|
||||
1. **Feature Slice Design:**
|
||||
- Организация кода вокруг функциональных блоков (фич).
|
||||
- Подходит для крупных проектов с множеством фич.
|
||||
2. **Domain-driven Design (DDD):**
|
||||
- Организация кода вокруг доменных областей (например, `user`, `order`, `product`).
|
||||
- Часто используется в бэкенд-разработке.
|
||||
@@ -2,4 +2,100 @@
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Atomic design
|
||||
# Atomic design
|
||||
Источник: DeepSeek
|
||||
|
||||
Atomic Design — это методология проектирования и организации пользовательских интерфейсов, предложенная Брэдом Фростом (Brad Frost). Она основана на идее разделения интерфейса на небольшие, независимые и переиспользуемые компоненты, которые затем комбинируются для создания более сложных структур. Название методологии вдохновлено химией: так же, как молекулы состоят из атомов, интерфейсы состоят из базовых компонентов.
|
||||
|
||||
## Основные принципы Atomic Design
|
||||
1. **Иерархия компонентов:**
|
||||
- Компоненты организуются в иерархию от простых к сложным.
|
||||
- Каждый уровень иерархии имеет своё назначение и уровень абстракции.
|
||||
2. **Переиспользуемость:**
|
||||
- Компоненты проектируются так, чтобы их можно было использовать в разных частях интерфейса.
|
||||
3. **Модульность:**
|
||||
- Каждый компонент изолирован и независим, что упрощает тестирование и поддержку.
|
||||
4. **Масштабируемость:**
|
||||
- Методология подходит как для небольших, так и для крупных проектов.
|
||||
|
||||
## Уровни Atomic Design
|
||||
1. Атомы (Atoms):
|
||||
- Наименьшие и базовые элементы интерфейса, которые нельзя разделить на более мелкие части.
|
||||
- Примеры: кнопки, инпуты, иконки, текстовые элементы.
|
||||
2. Молекулы (Molecules):
|
||||
- Комбинация нескольких атомов, которые вместе выполняют определённую функцию.
|
||||
- Примеры: форма поиска (инпут + кнопка), карточка товара (изображение + заголовок + цена).
|
||||
3. Организмы (Organisms):
|
||||
- Более сложные компоненты, состоящие из молекул и/или атомов.
|
||||
- Примеры: шапка сайта (логотип + навигация + форма поиска), футер (ссылки + текст + иконки).
|
||||
4. Шаблоны (Templates):
|
||||
- Макеты страниц, которые определяют структуру и расположение организмов.
|
||||
- Пример: шаблон главной страницы (шапка + список карточек товаров + футер).
|
||||
5. Страницы (Pages):
|
||||
- Конкретные реализации шаблонов с реальными данными.
|
||||
- Пример: главная страница сайта с заполненными карточками товаров.
|
||||
|
||||
## Пример структуры проекта с использованием Atomic Design
|
||||
```
|
||||
src/
|
||||
│
|
||||
├── components/
|
||||
│ ├── atoms/ # Атомы
|
||||
│ │ ├── Button/
|
||||
│ │ ├── Input/
|
||||
│ │ └── Text/
|
||||
│ │
|
||||
│ ├── molecules/ # Молекулы
|
||||
│ │ ├── SearchForm/ # Форма поиска (Input + Button)
|
||||
│ │ └── ProductCard/ # Карточка товара (Image + Text + Button)
|
||||
│ │
|
||||
│ ├── organisms/ # Организмы
|
||||
│ │ ├── Header/ # Шапка сайта (Logo + Navigation + SearchForm)
|
||||
│ │ └── Footer/ # Футер (Links + Text + Icons)
|
||||
│ │
|
||||
│ ├── templates/ # Шаблоны
|
||||
│ │ ├── HomeTemplate/ # Шаблон главной страницы
|
||||
│ │ └── ProductTemplate/# Шаблон страницы товара
|
||||
│ │
|
||||
│ └── pages/ # Страницы
|
||||
│ ├── HomePage/ # Главная страница
|
||||
│ └── ProductPage/ # Страница товара
|
||||
│
|
||||
└── App.tsx # Основной файл приложения
|
||||
```
|
||||
|
||||
## Преимущества Atomic Design
|
||||
1. **Переиспользуемость:**
|
||||
- Компоненты можно использовать в разных частях интерфейса, что сокращает дублирование кода.
|
||||
2. **Масштабируемость:**
|
||||
- Методология подходит для проектов любого размера.
|
||||
3. **Упрощение разработки:**
|
||||
- Чёткая структура помогает разработчикам быстро находить и изменять нужные компоненты.
|
||||
4. **Согласованность интерфейса:**
|
||||
- Использование атомов и молекул обеспечивает единообразие дизайна.
|
||||
5. **Упрощение тестирования:**
|
||||
- Компоненты можно тестировать изолированно.
|
||||
|
||||
## Недостатки Atomic Design
|
||||
1. **Сложность для небольших проектов:**
|
||||
- В маленьких проектах такая структура может показаться излишне сложной.
|
||||
2. **Требует дисциплины:**
|
||||
- Необходимо строго следовать принципам, чтобы избежать смешения уровней.
|
||||
3. **Ограниченная гибкость:**
|
||||
- В некоторых случаях строгая иерархия может ограничивать возможности кастомизации.
|
||||
|
||||
## Пример реализации Atomic Design
|
||||
1. **Атом:** Кнопка (Button)
|
||||
2. **Молекула:** Форма поиска (SearchForm)
|
||||
3. **Организм:** Шапка сайта (Header)
|
||||
4. **Шаблон:** Главная страница (HomeTemplate)
|
||||
5. **Страница:** Главная страница (HomePage)
|
||||
|
||||
## Когда использовать Atomic Design
|
||||
- В проектах с большим количеством переиспользуемых компонентов.
|
||||
- Когда требуется высокая согласованность интерфейса.
|
||||
- В командах, где дизайнеры и разработчики тесно взаимодействуют.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,4 +2,102 @@
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Доменная архитектура
|
||||
# Доменная архитектура
|
||||
Источник: DeepSeek
|
||||
|
||||
**Domain-Driven Design (DDD)** — это подход к разработке программного обеспечения, который фокусируется на моделировании бизнес-логики и организации кода вокруг доменных областей (бизнес-контекстов). Хотя DDD изначально был разработан для бэкенд-разработки, его принципы могут быть успешно применены и во фронтенде, особенно в сложных приложениях с богатой бизнес-логикой.
|
||||
|
||||
## Основные концепции DDD
|
||||
1. **Домен (Domain):**
|
||||
- Это предметная область, которую решает приложение (например, электронная коммерция, управление проектами, финансы).
|
||||
- Домен состоит из поддоменов (например, заказы, продукты, пользователи).
|
||||
2. **Модель (Model):**
|
||||
- Абстракция, которая описывает ключевые концепции и процессы в домене.
|
||||
- Модель включает сущности, значения, агрегаты и сервисы.
|
||||
3. **Ограниченный контекст (Bounded Context):**
|
||||
- Чётко определённая область, в которой применяется конкретная модель.
|
||||
- Например, в одном контексте "пользователь" может быть клиентом, а в другом — администратором.
|
||||
4. **Универсальный язык (Ubiquitous Language):**
|
||||
- Общий язык, который используется разработчиками, дизайнерами и бизнес-экспертами для описания домена.
|
||||
- Помогает избежать недопонимания и упрощает коммуникацию.
|
||||
5. **Слои (Layers):**
|
||||
- DDD разделяет приложение на слои: доменный слой, слой приложения, инфраструктурный слой и презентационный слой.
|
||||
|
||||
## Применение DDD во фронтенде
|
||||
Во фронтенде DDD может быть использован для организации кода вокруг бизнес-логики, что особенно полезно в сложных приложениях, таких как CRM-системы, платформы для электронной коммерции или аналитические панели.
|
||||
|
||||
## Основные принципы DDD во фронтенде
|
||||
1. **Организация кода вокруг доменов:**
|
||||
- Код структурируется по доменам, а не по техническим слоям (например, `components`, `pages`).
|
||||
- Каждый домен включает всё необходимое для своей работы: компоненты, логику, состояние, API-запросы.
|
||||
2. **Изоляция доменов:**
|
||||
- Домены максимально независимы друг от друга.
|
||||
- Это позволяет разрабатывать, тестировать и изменять их без влияния на другие части приложения.
|
||||
3. **Использование универсального языка:**
|
||||
- Названия компонентов, функций и переменных отражают бизнес-концепции, что делает код более понятным.
|
||||
4. **Фокус на бизнес-логике:**
|
||||
- Логика, связанная с доменом, выносится в отдельные модули, что упрощает её тестирование и поддержку.
|
||||
|
||||
Пример структуры проекта с использованием DDD
|
||||
```
|
||||
src/
|
||||
│
|
||||
├── domains/ # Домены
|
||||
│ ├── cart/ # Домен "Корзина"
|
||||
│ │ ├── components/ # Компоненты, специфичные для корзины
|
||||
│ │ ├── hooks/ # Хуки для корзины
|
||||
│ │ ├── store/ # Логика состояния (например, Redux slice)
|
||||
│ │ ├── api/ # API-запросы, связанные с корзиной
|
||||
│ │ └── index.ts # Экспорт домена
|
||||
│ │
|
||||
│ └── auth/ # Домен "Авторизация"
|
||||
│ ├── components/
|
||||
│ ├── hooks/
|
||||
│ ├── store/
|
||||
│ ├── api/
|
||||
│ └── index.ts
|
||||
│
|
||||
├── shared/ # Общие компоненты и утилиты
|
||||
│ ├── ui/ # UI-компоненты (кнопки, инпуты и т.д.)
|
||||
│ └── lib/ # Утилиты и хелперы
|
||||
│
|
||||
├── app/ # Основная логика приложения
|
||||
│ ├── routing/ # Роутинг
|
||||
│ ├── providers/ # Провайдеры (например, Redux, Theme)
|
||||
│ └── index.ts
|
||||
│
|
||||
└── pages/ # Страницы приложения
|
||||
├── HomePage/ # Страница "Главная"
|
||||
└── ProfilePage/ # Страница "Профиль"
|
||||
```
|
||||
|
||||
## Преимущества DDD во фронтенде
|
||||
1. **Чёткая структура:**
|
||||
- Код организуется вокруг бизнес-контекстов, что делает его более понятным.
|
||||
2. **Упрощение разработки:**
|
||||
- Разработчики могут фокусироваться на одной доменной области, не отвлекаясь на остальные части приложения.
|
||||
3. **Улучшение поддерживаемости:**
|
||||
- Изменения в одном домене не затрагивают другие.
|
||||
4. **Гибкость:**
|
||||
- Домены можно легко добавлять, удалять или заменять.
|
||||
5. **Тестируемость:**
|
||||
- Бизнес-логика может быть протестирована изолированно.
|
||||
|
||||
## Недостатки DDD во фронтенде
|
||||
1. **Сложность для небольших проектов:**
|
||||
- В маленьких приложениях такая структура может показаться излишне сложной.
|
||||
2. **Требует глубокого понимания домена:**
|
||||
- Необходимо тесное взаимодействие с бизнес-экспертами.
|
||||
3. **Оверхеад:**
|
||||
- Требуется время и усилия для правильной организации кода.
|
||||
|
||||
## Пример реализации домена "Корзина"
|
||||
1. Компонент: CartList
|
||||
2. Хук: useCart
|
||||
3. Redux slice: cartSlice
|
||||
4. API: cartApi
|
||||
|
||||
## Когда использовать DDD во фронтенде
|
||||
В сложных приложениях с богатой бизнес-логикой.
|
||||
В командах, где разработчики и бизнес-эксперты тесно взаимодействуют.
|
||||
Когда требуется высокая степень модульности и переиспользуемости.
|
||||
@@ -3,6 +3,7 @@ sidebar_position: 5
|
||||
---
|
||||
|
||||
# Feature slice design
|
||||
Источник: DeepSeek
|
||||
|
||||
**Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@ sidebar_position: 6
|
||||
---
|
||||
|
||||
# Micro frontend
|
||||
Источник: DeepSeek
|
||||
|
||||
Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений.
|
||||
|
||||
|
||||
@@ -3,6 +3,7 @@ sidebar_position: 7
|
||||
---
|
||||
|
||||
# Test driven development
|
||||
Источник: DeepSeek
|
||||
|
||||
TDD (Test-Driven Development) — это методология разработки программного обеспечения, в которой написание тестов предшествует написанию кода. Основная идея TDD заключается в том, что разработчик сначала пишет тест для новой функциональности, а затем реализует код, который делает этот тест успешным. Этот процесс повторяется для каждой новой функции или улучшения.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user