refactor: move big from n to arch

docs/architecture/03-ddd-domain-driven-design.md

@@ -0,0 +1,104 @@
+---
+sidebar_position: 3
+---
+
+# Доменная архитектура
+
+**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 во фронтенде
+В сложных приложениях с богатой бизнес-логикой.
+В командах, где разработчики и бизнес-эксперты тесно взаимодействуют.
+Когда требуется высокая степень модульности и переиспользуемости.
+
+🚀 **_Источник: DeepSeek_**