diff --git a/modules/module1/sections/01-role-and-responsibilities.md b/modules/module1/sections/01-role-and-responsibilities.md
index e82179d..cc2e493 100644
--- a/modules/module1/sections/01-role-and-responsibilities.md
+++ b/modules/module1/sections/01-role-and-responsibilities.md
@@ -99,70 +99,781 @@ public class OrderController {
### 1. Анализ требований (Requirements Analysis)
**Входные данные:**
-- Бизнес-требования (Business Requirements)
-- Функциональные требования (Functional Requirements)
-- Нефункциональные требования (Non-Functional Requirements)
-- Ограничения (Constraints)
+
+### 1. Бизнес-требования (Business Requirements)
+
+**Определение:** Высокоуровневые цели и потребности организации, которые должны быть достигнуты с помощью IT-решения.
+
+**Типы бизнес-требований:**
+
+#### 1.1 Стратегические требования
+- **Бизнес-цели:** Увеличение прибыли, выход на новые рынки, оптимизация процессов
+- **Конкурентные преимущества:** Уникальные возможности, которые отличают от конкурентов
+- **Стратегические инициативы:** Долгосрочные планы развития компании
+
+**Пример:**
+
+| Стратегическая цель | Описание | Временные рамки |
+|---------------------|----------|-----------------|
+| **Увеличение доли рынка** | Увеличить долю рынка на 15% | 2 года |
+| **Оптимизация процессов** | Сократить время обработки заказов на 50% | 1 год |
+| **Международная экспансия** | Выйти на международный рынок | 3 года |
+
+#### 1.2 Операционные требования
+- **Бизнес-процессы:** Текущие и желаемые процессы работы
+- **Пользовательские роли:** Кто будет использовать систему
+- **Интеграции:** Связь с существующими системами
+
+**Пример:**
+
+| Категория | Элемент | Описание |
+|-----------|---------|----------|
+| **Бизнес-процессы** | Обработка заказов | Обработка заказов клиентов |
+| | Управление складом | Управление складскими запасами |
+| | Отчетность | Генерация отчетов для руководства |
+| **Пользовательские роли** | Менеджер по продажам | Работа с клиентами и заказами |
+| | Складской работник | Управление инвентарем |
+| | Финансовый аналитик | Анализ финансовых показателей |
+
+#### 1.3 Финансовые требования
+- **Бюджет проекта:** Доступные финансовые ресурсы
+- **ROI ожидания:** Ожидаемая окупаемость инвестиций
+- **Операционные расходы:** Постоянные затраты на поддержку
+
+### 2. Функциональные требования (Functional Requirements)
+
+**Определение:** Конкретные функции и возможности, которые должна выполнять система.
+
+#### 2.1 Пользовательские сценарии (User Stories)
+- **Формат:** "Как [роль], я хочу [функция], чтобы [цель]"
+- **Критерии приемки:** Условия, при которых требование считается выполненным
+
+**Пример:**
+
+| User Story | Критерии приемки |
+|------------|------------------|
+| **Как менеджер по продажам, я хочу видеть историю заказов клиента, чтобы лучше понимать его потребности** | • Система отображает все заказы клиента за последние 2 года
• Заказы отсортированы по дате (новые сверху)
• Доступен поиск по номеру заказа |
+
+#### 2.2 Бизнес-правила (Business Rules)
+- **Валидация данных:** Правила проверки корректности информации
+- **Автоматизация процессов:** Логика автоматических действий
+- **Ограничения доступа:** Кто и к чему имеет доступ
+
+**Пример:**
+
+| Категория | Правило | Описание |
+|-----------|---------|----------|
+| **Валидация данных** | Email валидация | Email должен содержать символ @ и домен |
+| | Телефон валидация | Телефон должен содержать 11 цифр |
+| | Сумма заказа | Сумма заказа не может быть отрицательной |
+| **Автоматизация процессов** | Кредитный лимит | При превышении лимита кредита заказ автоматически отклоняется |
+| | Уведомления | Уведомление отправляется при изменении статуса заказа |
+
+#### 2.3 Интеграционные требования
+- **API интеграции:** Связь с внешними системами
+- **Обмен данными:** Форматы и протоколы передачи
+- **Синхронизация:** Частота обновления данных
+
+**Пример:**
+
+| Категория | Система/Формат | Описание |
+|-----------|----------------|----------|
+| **Внешние системы** | CRM система | Salesforce |
+| | Платежный шлюз | Stripe |
+| | Система логистики | 1C |
+| **Форматы данных** | REST API | JSON |
+| | SOAP сервисы | XML |
+| | Массовые операции | CSV |
+
+### 3. Нефункциональные требования (Non-Functional Requirements)
+
+**Определение:** Качественные характеристики системы, определяющие как система должна работать.
+
+#### 3.1 Производительность (Performance)
+- **Время отклика:** Максимальное время ответа системы
+- **Пропускная способность:** Количество операций в единицу времени
+- **Масштабируемость:** Способность обрабатывать увеличение нагрузки
+
+**Пример:**
+
+| Категория | Требование | Значение |
+|-----------|------------|----------|
+| **Время отклика** | Обычные запросы | 95% запросов менее чем за 2 секунды |
+| | Критические операции | Менее 500мс |
+| **Пропускная способность** | Одновременные пользователи | 1000 пользователей |
+| | Транзакции | 10,000 транзакций в минуту |
+| **Масштабируемость** | Горизонтальное масштабирование | До 10 серверов |
+| | Автоматическое масштабирование | При нагрузке >80% |
+
+#### 3.2 Надежность (Reliability)
+- **Доступность:** Процент времени работы системы
+- **Отказоустойчивость:** Способность работать при сбоях
+- **Восстановление:** Время восстановления после сбоя
+
+**Пример:**
+
+| Категория | Требование | Значение |
+|-----------|------------|----------|
+| **Доступность** | Uptime | 99.9% (8.76 часов простоя в год) |
+| | Плановые работы | Только в выходные |
+| **Отказоустойчивость** | Отказ сервера | Система продолжает работать при отказе одного сервера |
+| | Переключение | Автоматическое переключение на резервный сервер |
+| **Восстановление** | Восстановление данных | За последние 24 часа |
+| | RTO | Recovery Time Objective - 4 часа |
+
+#### 3.3 Безопасность (Security)
+- **Аутентификация:** Проверка личности пользователя
+- **Авторизация:** Контроль доступа к ресурсам
+- **Шифрование:** Защита данных при передаче и хранении
+
+**Пример:**
+
+| Категория | Требование | Описание |
+|-----------|------------|----------|
+| **Аутентификация** | 2FA для администраторов | Двухфакторная аутентификация для администраторов |
+| | Active Directory | Интеграция с Active Directory |
+| | Сессии | Сессии истекают через 30 минут неактивности |
+| **Авторизация** | RBAC | Ролевая модель доступа (RBAC) |
+| | Принцип минимальных привилегий | Принцип минимальных привилегий |
+| **Шифрование** | TLS 1.3 | TLS 1.3 для передачи данных |
+| | AES-256 | AES-256 для хранения чувствительных данных |
+| | Хеширование паролей | Хеширование паролей с солью |
+
+#### 3.4 Совместимость (Compatibility)
+- **Браузеры:** Поддерживаемые веб-браузеры
+- **Операционные системы:** Совместимость с ОС
+- **Мобильные устройства:** Поддержка мобильных платформ
+
+**Пример:**
+
+| Категория | Платформа | Версия |
+|-----------|-----------|--------|
+| **Браузеры** | Chrome | 90+ |
+| | Firefox | 88+ |
+| | Safari | 14+ |
+| | Edge | 90+ |
+| **Операционные системы** | Windows | 10+ |
+| | macOS | 11+ |
+| | Ubuntu | 20.04+ |
+| **Мобильные устройства** | iOS | 14+ |
+| | Android | 10+ |
+| | Responsive design | Все устройства |
+
+#### 3.5 Удобство использования (Usability)
+- **Пользовательский интерфейс:** Простота и интуитивность
+- **Обучение:** Время, необходимое для освоения системы
+- **Доступность:** Поддержка пользователей с ограниченными возможностями
+
+**Пример:**
+
+| Категория | Требование | Описание |
+|-----------|------------|----------|
+| **Пользовательский интерфейс** | Интуитивность | Интуитивно понятный интерфейс |
+| | Навигация | Максимум 3 клика для основных операций |
+| | Справка | Контекстная справка |
+| **Обучение** | Время освоения | Новый пользователь может выполнить основные задачи за 30 минут |
+| | Документация | Онлайн-документация и видео-туториалы |
+| **Доступность** | WCAG 2.1 AA | Соответствие WCAG 2.1 AA |
+| | Скрин-ридеры | Поддержка скрин-ридеров |
+| | Навигация | Клавиатурная навигация |
+
+### 4. Ограничения (Constraints)
+
+**Определение:** Ограничения, которые влияют на архитектурные решения и выбор технологий.
+
+#### 4.1 Технические ограничения
+- **Существующая инфраструктура:** Текущие системы и технологии
+- **Технологический стек:** Предпочтения по языкам и фреймворкам
+- **Интеграции:** Ограничения существующих систем
+
+**Пример:**
+
+| Категория | Ограничение | Описание |
+|-----------|-------------|----------|
+| **Существующая инфраструктура** | Дата-центр | Использование существующего дата-центра |
+| | База данных | Совместимость с Oracle Database 19c |
+| | ERP система | Интеграция с SAP ERP |
+| **Технологический стек** | Backend | Java 11+ для backend |
+| | Frontend | React для frontend |
+| | База данных | PostgreSQL для новых модулей |
+| **Интеграции** | 1C интеграция | SOAP API для интеграции с 1C |
+| | Мобильное приложение | REST API для мобильного приложения |
+
+#### 4.2 Бюджетные ограничения
+- **Общий бюджет:** Доступные финансовые ресурсы
+- **Распределение бюджета:** Разделение по этапам и компонентам
+- **Операционные расходы:** Постоянные затраты на поддержку
+
+**Пример:**
+
+| Категория | Статья расходов | Сумма | Процент |
+|-----------|-----------------|-------|---------|
+| **Общий бюджет** | Общий бюджет проекта | 5,000,000 руб. | 100% |
+| **Распределение бюджета** | Разработка | 3,000,000 руб. | 60% |
+| | Инфраструктура | 1,000,000 руб. | 20% |
+| | Тестирование | 500,000 руб. | 10% |
+| | Обучение | 500,000 руб. | 10% |
+| **Операционные расходы** | Ежемесячно | 200,000 руб. | - |
+| | Ежегодно | 2,400,000 руб. | - |
+
+#### 4.3 Временные ограничения
+- **Дедлайны:** Критические даты завершения
+- **Этапы проекта:** Временные рамки для каждого этапа
+- **Ресурсы:** Доступность команды разработки
+
+**Пример:**
+
+| Категория | Этап/Ресурс | Временные рамки | Команда |
+|-----------|-------------|-----------------|---------|
+| **Дедлайн проекта** | Финальная дата | 2024-12-31 | - |
+| **Этапы проекта** | Анализ | 2024-01-01 - 2024-02-28 | Architecture Team |
+| | Проектирование | 2024-03-01 - 2024-04-30 | Architecture + Backend |
+| | Разработка | 2024-05-01 - 2024-10-31 | Все команды |
+| | Тестирование | 2024-11-01 - 2024-12-15 | QA + Backend |
+| **Ресурсы** | Размер команды | 8 разработчиков | - |
+| | Доступность | 40 часов в неделю | - |
+
+#### 4.4 Регулятивные ограничения
+- **Соответствие стандартам:** Требования к сертификации
+- **Защита данных:** GDPR, 152-ФЗ и другие регуляции
+- **Отраслевые стандарты:** Специфические требования отрасли
+
+**Пример:**
+
+| Категория | Стандарт/Требование | Описание |
+|-----------|---------------------|----------|
+| **Защита данных** | 152-ФЗ | Соответствие 152-ФЗ 'О персональных данных' |
+| | GDPR | GDPR для европейских пользователей |
+| | Локальное хранение | Локальное хранение данных в России |
+| **Отраслевые стандарты** | PCI DSS | PCI DSS для обработки платежей |
+| | ISO 27001 | ISO 27001 для информационной безопасности |
+| | ГОСТ Р 57580.1-2017 | ГОСТ Р 57580.1-2017 для банковских систем |
+| **Соответствие** | Аудит безопасности | Аудит безопасности каждые 6 месяцев |
+| | Логирование | Ведение логов доступа к персональным данным |
+| | Уведомления | Уведомление регуляторов о инцидентах |
+
+#### 4.5 Организационные ограничения
+- **Культура компании:** Принятые в организации подходы
+- **Процессы:** Существующие методологии разработки
+- **Команда:** Навыки и опыт доступных специалистов
+
+**Пример:**
+
+| Категория | Элемент | Описание |
+|-----------|---------|----------|
+| **Культура компании** | Методология | Agile/Scrum методология |
+| | Демо | Еженедельные демо для стейкхолдеров |
+| | Принятие решений | Коллективное принятие решений |
+| **Процессы** | Code Review | Code review обязателен для всех изменений |
+| | Тестирование | Автоматизированное тестирование |
+| | CI/CD | Continuous Integration/Deployment |
+| **Навыки команды** | Java, Spring Boot | Экспертный уровень |
+| | React, TypeScript | Средний уровень |
+| | DevOps, Kubernetes | Начальный уровень |
**Процесс анализа:**
-```java
-// Пример анализа требований
-public class RequirementsAnalyzer {
+
+
+```mermaid
+flowchart LR
+ A[Бизнес-требования] --> B[Анализ требований]
- public ArchitectureRequirements analyzeRequirements(BusinessRequirements businessReq) {
- ArchitectureRequirements archReq = new ArchitectureRequirements();
-
- // Анализ функциональных требований
- analyzeFunctionalRequirements(businessReq, archReq);
-
- // Анализ нефункциональных требований
- analyzeNonFunctionalRequirements(businessReq, archReq);
-
- // Анализ ограничений
- analyzeConstraints(businessReq, archReq);
-
- return archReq;
- }
+ B --> C[Функциональные требования]
+ B --> D[Нефункциональные требования]
+ B --> E[Ограничения]
- private void analyzeNonFunctionalRequirements(BusinessRequirements businessReq,
- ArchitectureRequirements archReq) {
- // Производительность
- if (businessReq.getExpectedUsers() > 10000) {
- archReq.addRequirement("HIGH_PERFORMANCE", "System must handle 10k+ concurrent users");
- }
-
- // Масштабируемость
- if (businessReq.isGlobalDeployment()) {
- archReq.addRequirement("SCALABILITY", "System must scale globally");
- }
-
- // Безопасность
- if (businessReq.isFinancialData()) {
- archReq.addRequirement("SECURITY", "Financial data must be encrypted");
- }
- }
-}
+ C --> C1[Пользовательские сценарии]
+ C --> C2[Бизнес-процессы]
+ C --> C3[Интеграции]
+
+ D --> D1[Производительность]
+ D --> D2[Масштабируемость]
+ D --> D3[Безопасность]
+ D --> D4[Надежность]
+ D --> D5[Совместимость]
+
+ E --> E1[Бюджетные ограничения]
+ E --> E2[Временные рамки]
+ E --> E3[Технические ограничения]
+ E --> E4[Регулятивные требования]
+
+ C1 --> F[Архитектурные требования]
+ C2 --> F
+ C3 --> F
+ D1 --> F
+ D2 --> F
+ D3 --> F
+ D4 --> F
+ D5 --> F
+ E1 --> F
+ E2 --> F
+ E3 --> F
+ E4 --> F
+
+ F --> G[Приоритизация требований]
+ G --> H[Архитектурные решения]
+
+ style A fill:#e1f5fe
+ style B fill:#f3e5f5
+ style F fill:#e8f5e8
+ style G fill:#fff3e0
+ style H fill:#fce4ec
```
### 2. Проектирование архитектуры (Architecture Design)
-**Этапы проектирования:**
+**Определение:** Процесс создания технической архитектуры системы на основе проанализированных требований и ограничений.
-1. **Высокоуровневое проектирование**
- - Определение основных компонентов
- - Выбор архитектурного стиля
- - Определение интерфейсов
+#### 2.1 Высокоуровневое проектирование (High-Level Design)
-2. **Детальное проектирование**
- - Проектирование компонентов
- - Выбор технологий
- - Определение паттернов взаимодействия
+**Цель:** Создание общей архитектурной концепции системы.
-3. **Валидация архитектуры**
- - Проверка соответствия требованиям
- - Анализ рисков
- - Прототипирование критических компонентов
+##### 2.1.1 Определение основных компонентов
+
+**Процесс выделения компонентов:**
+
+```mermaid
+flowchart TD
+ A[Анализ бизнес-процессов] --> B[Выделение доменов]
+ B --> C[Определение границ компонентов]
+ C --> D[Выделение основных компонентов]
+
+ D --> E[Пользовательский интерфейс]
+ D --> F[Бизнес-логика]
+ D --> G[Доступ к данным]
+ D --> H[Внешние интеграции]
+
+ E --> E1[Web-приложение]
+ E --> E2[Мобильное приложение]
+ E --> E3[API Gateway]
+
+ F --> F1[Сервис заказов]
+ F --> F2[Сервис пользователей]
+ F --> F3[Сервис платежей]
+
+ G --> G1[База данных]
+ G --> G2[Кэш]
+ G --> G3[Файловое хранилище]
+
+ H --> H1[Платежный шлюз]
+ H --> H2[CRM система]
+ H --> H3[Email сервис]
+
+ style A fill:#e1f5fe
+ style D fill:#f3e5f5
+ style E fill:#e8f5e8
+ style F fill:#fff3e0
+ style G fill:#fce4ec
+ style H fill:#f1f8e9
+```
+
+**Пример выделения компонентов для e-commerce системы:**
+
+| Слой | Компонент | Технология | Описание |
+|------|-----------|------------|----------|
+| **Presentation Layer** | Web Frontend | React | Пользовательский интерфейс |
+| | Mobile App | React Native | Мобильное приложение |
+| | Admin Panel | Vue.js | Панель администратора |
+| | API Gateway | Kong | Единая точка входа |
+| **Business Logic Layer** | User Service | - | Аутентификация, профили |
+| | Product Service | - | Каталог, поиск |
+| | Order Service | - | Корзина, заказы |
+| | Payment Service | - | Обработка платежей |
+| | Notification Service | - | Уведомления |
+| **Data Layer** | User Database | PostgreSQL | База данных пользователей |
+| | Product Database | MongoDB | База данных товаров |
+| | Order Database | PostgreSQL | База данных заказов |
+| | Cache | Redis | Кэширование |
+| | File Storage | AWS S3 | Файловое хранилище |
+| **Integration Layer** | Payment Gateway | Stripe | Платежный шлюз |
+| | Email Service | SendGrid | Email сервис |
+| | SMS Service | Twilio | SMS сервис |
+| | Analytics | Google Analytics | Аналитика |
+
+##### 2.1.2 Выбор архитектурного стиля
+
+**Критерии выбора архитектурного стиля:**
+
+| Критерий | Монолит | Микросервисы | SOA | Event-Driven |
+|----------|---------|--------------|-----|--------------|
+| **Сложность проекта** | Низкая-Средняя | Высокая | Средняя-Высокая | Высокая |
+| **Размер команды** | 1-10 | 10+ | 5-20 | 10+ |
+| **Время разработки** | Быстрое | Медленное | Среднее | Медленное |
+| **Масштабируемость** | Ограниченная | Высокая | Средняя | Высокая |
+| **Отказоустойчивость** | Низкая | Высокая | Средняя | Высокая |
+| **Сложность развертывания** | Простая | Сложная | Средняя | Сложная |
+
+**Пример выбора архитектурного стиля:**
+
+**Характеристики проекта:**
+
+| Параметр | Значение |
+|----------|----------|
+| **Размер команды** | 15 разработчиков |
+| **Длительность проекта** | 18 месяцев |
+| **Ожидаемое количество пользователей** | 100,000+ |
+| **Количество бизнес-доменов** | 5 основных доменов |
+| **Сложность интеграций** | Высокая |
+| **Требования к масштабируемости** | Высокие |
+
+**Матрица принятия решений:**
+
+| Архитектурный стиль | Преимущества | Недостатки | Оценка | Решение |
+|---------------------|--------------|------------|--------|---------|
+| **Микросервисы** | • Независимая разработка команд
• Технологическое разнообразие
• Горизонтальное масштабирование
• Отказоустойчивость | • Сложность развертывания
• Сетевые задержки
• Управление данными
• Мониторинг | **8.5/10** | ✅ **Выбран** |
+| **Монолит** | • Простота разработки
• Быстрое развертывание
• Простой мониторинг
• ACID транзакции | • Ограниченное масштабирование
• Технологическая привязка
• Единая точка отказа
• Сложность изменений | **5.0/10** | ❌ Не выбран |
+| **SOA** | • Переиспользование сервисов
• Стандартизация
• Интеграция legacy систем | • Сложность управления
• Производительность
• Vendor lock-in | **6.5/10** | ❌ Не выбран |
+| **Event-Driven** | • Слабая связанность
• Высокая масштабируемость
• Асинхронная обработка | • Сложность отладки
• Eventual consistency
• Сложность тестирования | **7.0/10** | ❌ Резервный вариант |
+
+**Критерии оценки:**
+
+| Критерий | Вес | Микросервисы | Монолит | SOA | Event-Driven |
+|----------|-----|--------------|---------|-----|--------------|
+| **Масштабируемость** | 25% | 9/10 | 3/10 | 6/10 | 9/10 |
+| **Скорость разработки** | 20% | 6/10 | 9/10 | 7/10 | 5/10 |
+| **Отказоустойчивость** | 20% | 9/10 | 3/10 | 6/10 | 8/10 |
+| **Сложность развертывания** | 15% | 4/10 | 9/10 | 6/10 | 5/10 |
+| **Управление командой** | 10% | 9/10 | 4/10 | 6/10 | 7/10 |
+| **Технологическое разнообразие** | 10% | 9/10 | 2/10 | 7/10 | 8/10 |
+
+**Итоговое решение:**
+
+| Решение | Обоснование |
+|---------|-------------|
+| **Микросервисная архитектура** | • Большая команда (15 разработчиков) позволяет эффективно работать с микросервисами
• Множественные домены (5) идеально подходят для разделения на сервисы
• Высокие требования к масштабируемости (100,000+ пользователей)
• Необходимость независимой разработки и развертывания компонентов
• Планируемая долгосрочная поддержка системы (18 месяцев) |
+
+**План миграции:**
+
+| Этап | Описание | Временные рамки | Команда |
+|------|----------|-----------------|---------|
+| **1. Подготовка** | Настройка инфраструктуры, CI/CD, мониторинга | 1-2 месяца | DevOps + Architecture |
+| **2. Пилотный сервис** | Выделение одного домена в микросервис | 2-3 месяца | Backend Team |
+| **3. Масштабирование** | Постепенное выделение остальных сервисов | 6-8 месяцев | Все команды |
+| **4. Оптимизация** | Настройка производительности и мониторинга | 2-3 месяца | DevOps + Backend |
+
+##### 2.1.3 Определение интерфейсов
+
+**Типы интерфейсов в архитектуре:**
+
+```mermaid
+graph TB
+ A[Интерфейсы системы] --> B[Внешние интерфейсы]
+ A --> C[Внутренние интерфейсы]
+
+ B --> B1[REST API]
+ B --> B2[GraphQL API]
+ B --> B3[WebSocket]
+ B --> B4[gRPC]
+
+ C --> C1[Service-to-Service]
+ C --> C2[Database Interfaces]
+ C --> C3[Message Queues]
+ C --> C4[Event Streams]
+
+ B1 --> B1a["HTTP/HTTPS
JSON формат
RESTful принципы"]
+ B2 --> B2a["HTTP/HTTPS
GraphQL схема
Типизированные запросы"]
+ B3 --> B3a["WebSocket протокол
Real-time обновления
Двунаправленная связь"]
+ B4 --> B4a["HTTP/2
Protocol Buffers
Высокая производительность"]
+
+ C1 --> C1a["Внутренние API
Service Mesh
Circuit Breaker"]
+ C2 --> C2a["ORM/ODM
Database Drivers
Connection Pooling"]
+ C3 --> C3a["RabbitMQ
Apache Kafka
Message Patterns"]
+ C4 --> C4a["Event Sourcing
CQRS
Event Store"]
+
+ style A fill:#e1f5fe
+ style B fill:#f3e5f5
+ style C fill:#e8f5e8
+```
+
+**Пример спецификации API интерфейса:**
+
+| Параметр | Значение |
+|----------|----------|
+| **Base URL** | https://api.company.com/v1 |
+| **Аутентификация** | JWT Bearer Token |
+
+**Endpoints:**
+
+| Endpoint | Method | Path | Описание |
+|----------|--------|------|----------|
+| **Create Order** | POST | /orders | Создание нового заказа |
+| **Get Order** | GET | /orders/{order_id} | Получение заказа по ID |
+| **Update Status** | PATCH | /orders/{order_id}/status | Обновление статуса заказа |
+
+**Request/Response схемы:**
+
+| Endpoint | Request Body | Response (200/201) | Error Responses |
+|----------|--------------|-------------------|-----------------|
+| **Create Order** | • customer_id (string, required)
• items (array)
• shipping_address (object)
• payment_method (string) | • order_id (string)
• status (string)
• total_amount (number)
• estimated_delivery (datetime) | • 400: Bad Request
• 401: Unauthorized
• 500: Internal Server Error |
+| **Get Order** | order_id (path parameter) | • order (object)
• status (string)
• tracking_info (object) | • 401: Unauthorized
• 404: Not Found
• 500: Internal Server Error |
+| **Update Status** | status (enum: pending, confirmed, shipped, delivered, cancelled) | • message (string)
• updated_at (datetime) | • 400: Bad Request
• 401: Unauthorized
• 404: Not Found
• 500: Internal Server Error |
+
+#### 2.2 Детальное проектирование (Detailed Design)
+
+**Цель:** Создание детальной технической спецификации каждого компонента.
+
+##### 2.2.1 Проектирование компонентов
+
+**Методология проектирования компонентов:**
+
+```mermaid
+flowchart LR
+ A[Анализ требований компонента] --> B[Определение ответственности]
+ B --> C[Проектирование интерфейсов]
+ C --> D[Выбор технологий]
+ D --> E[Проектирование данных]
+ E --> F[Обработка ошибок]
+ F --> G[Логирование и мониторинг]
+ G --> H[Тестирование]
+
+ style A fill:#e1f5fe
+ style B fill:#f3e5f5
+ style C fill:#e8f5e8
+ style D fill:#fff3e0
+ style E fill:#fce4ec
+ style F fill:#f1f8e9
+ style G fill:#e0f2f1
+ style H fill:#fff8e1
+```
+
+**Пример детального проектирования Order Service:**
+
+**Ответственность компонента:**
+
+| Уровень | Ответственность |
+|---------|-----------------|
+| **Основная** | Управление жизненным циклом заказов |
+| **Вторичная** | • Валидация заказов
• Расчет стоимости
• Управление статусами
• Интеграция с платежными системами |
+
+**Внутренняя структура:**
+
+| Слой | Компонент | Описание |
+|------|-----------|----------|
+| **Controllers** | OrderController | REST endpoints |
+| | OrderStatusController | Управление статусами |
+| | OrderValidationController | Валидация данных |
+| **Services** | OrderService | Бизнес-логика |
+| | PaymentService | Интеграция с платежами |
+| | NotificationService | Уведомления |
+| | InventoryService | Проверка наличия |
+| **Repositories** | OrderRepository | Доступ к данным заказов |
+| | OrderItemRepository | Позиции заказа |
+| | OrderStatusRepository | История статусов |
+| **Models** | Order | Основная модель заказа |
+| | OrderItem | Позиция заказа |
+| | OrderStatus | Статус заказа |
+| | OrderEvent | События заказа |
+
+**Поток данных:**
+
+| Операция | Шаги выполнения |
+|----------|-----------------|
+| **Create Order** | 1. Валидация входных данных
2. Проверка наличия товаров
3. Расчет стоимости
4. Создание заказа в БД
5. Отправка события OrderCreated
6. Инициация платежа |
+| **Update Status** | 1. Валидация нового статуса
2. Обновление в БД
3. Отправка события OrderStatusChanged
4. Уведомление клиента
5. Обновление инвентаря (если доставлен) |
+
+##### 2.2.2 Выбор технологий
+
+**Матрица выбора технологий:**
+
+**Backend Framework:**
+
+| Технология | Преимущества | Недостатки | Оценка | Решение |
+|------------|--------------|------------|--------|---------|
+| **Spring Boot** | • Богатая экосистема
• Enterprise готовность
• Отличная документация
• Spring Security | • Высокое потребление памяти
• Сложность для простых задач | **9.0/10** | ✅ **Выбран** |
+| **Node.js + Express** | • Быстрая разработка
• JavaScript везде
• Большое сообщество | • Однопоточность
• Менее подходит для CPU-intensive задач | **7.0/10** | ❌ Не выбран |
+
+**База данных:**
+
+| Тип | Технология | Обоснование выбора |
+|-----|------------|-------------------|
+| **Основная** | PostgreSQL | • ACID транзакции для заказов
• JSON поддержка для гибких данных
• Отличная производительность
• Надежность и стабильность |
+| **Вторичная** | Redis | • Кэширование часто запрашиваемых данных
• Сессии пользователей
• Очереди задач |
+
+**Message Queue:**
+
+| Технология | Обоснование выбора |
+|------------|-------------------|
+| **Apache Kafka** | • Высокая пропускная способность
• Надежность доставки
• Горизонтальное масштабирование
• Event sourcing поддержка |
+
+##### 2.2.3 Определение паттернов взаимодействия
+
+**Архитектурные паттерны для микросервисов:**
+
+```mermaid
+graph TB
+ A[Паттерны взаимодействия] --> B[Синхронные паттерны]
+ A --> C[Асинхронные паттерны]
+ A --> D[Паттерны данных]
+
+ B --> B1[API Gateway]
+ B --> B2[Service Mesh]
+ B --> B3[Circuit Breaker]
+ B --> B4[Load Balancer]
+
+ C --> C1[Event Sourcing]
+ C --> C2[CQRS]
+ C --> C3[Saga Pattern]
+ C --> C4[Message Queue]
+
+ D --> D1[Database per Service]
+ D --> D2[Shared Database]
+ D --> D3[Event Store]
+ D --> D4[Data Lake]
+
+ B1 --> B1a["Единая точка входа
Аутентификация
Rate Limiting"]
+ B2 --> B2a["Service Discovery
Load Balancing
Security"]
+ B3 --> B3a["Отказоустойчивость
Fallback механизмы
Мониторинг"]
+
+ C1 --> C1a["История изменений
Audit Trail
Восстановление состояния"]
+ C2 --> C2a["Разделение чтения/записи
Оптимизация запросов
Масштабируемость"]
+ C3 --> C3a["Распределенные транзакции
Компенсирующие действия
Консистентность"]
+
+ style A fill:#e1f5fe
+ style B fill:#f3e5f5
+ style C fill:#e8f5e8
+ style D fill:#fff3e0
+```
+
+**Пример реализации Saga Pattern для заказа:**
+
+**Шаги Saga:**
+
+| Шаг | Действие | Компенсация | Сервис | Timeout | Зависимость |
+|-----|----------|-------------|--------|---------|-------------|
+| **Step 1** | CreateOrder | CancelOrder | OrderService | 30 секунд | - |
+| **Step 2** | ReserveInventory | ReleaseInventory | InventoryService | 10 секунд | Step 1 |
+| **Step 3** | ProcessPayment | RefundPayment | PaymentService | 60 секунд | Step 2 |
+| **Step 4** | SendOrderConfirmation | SendOrderCancellation | NotificationService | 5 секунд | Step 3 |
+
+**Saga Orchestrator:**
+
+| Параметр | Значение |
+|----------|----------|
+| **Реализация** | Spring State Machine |
+| **Персистентность** | PostgreSQL |
+| **Мониторинг** | Prometheus metrics |
+
+**Обработка ошибок:**
+
+| Категория | Параметр | Значение |
+|-----------|----------|----------|
+| **Retry Policy** | Максимальные попытки | 3 |
+| | Стратегия backoff | Exponential |
+| | Начальная задержка | 1 секунда |
+| **Compensation Strategy** | Автоматическая | true |
+| | Timeout | 5 минут |
+| | Уведомления | Saga failed notification |
+
+#### 2.3 Валидация архитектуры (Architecture Validation)
+
+**Цель:** Проверка соответствия архитектуры требованиям и выявление потенциальных проблем.
+
+##### 2.3.1 Проверка соответствия требованиям
+
+**Матрица соответствия требований:**
+
+**Функциональные требования:**
+
+| Требование | Архитектурное решение | Статус | Детали реализации |
+|------------|----------------------|--------|-------------------|
+| **Аутентификация пользователей через OAuth 2.0** | API Gateway с JWT токенами + OAuth 2.0 провайдер | ✅ Соответствует | Auth0 интеграция в API Gateway |
+| **Обработка 1000 заказов в минуту** | Микросервис Order Service с горизонтальным масштабированием | ✅ Соответствует | Kubernetes HPA + Load Balancer |
+
+**Нефункциональные требования:**
+
+| Требование | Архитектурное решение | Статус | Детали реализации |
+|------------|----------------------|--------|-------------------|
+| **95% запросов менее чем за 2 секунды** | Кэширование + CDN + оптимизированные запросы к БД | ✅ Соответствует | Redis кэш + CloudFlare CDN + индексы БД |
+| **99.9% uptime** | Кластерная архитектура + автоматическое восстановление | ✅ Соответствует | Kubernetes + Health Checks + Circuit Breakers |
+
+##### 2.3.2 Анализ рисков
+
+**Матрица рисков архитектуры:**
+
+**Технические риски:**
+
+| Риск | Описание | Вероятность | Воздействие | Митигация | Ответственный | Временные рамки |
+|------|----------|-------------|-------------|-----------|---------------|-----------------|
+| **Database Bottleneck** | PostgreSQL может стать узким местом при высокой нагрузке | Средняя | Высокий | • Горизонтальное шардирование
• Read replicas для запросов на чтение
• Кэширование часто запрашиваемых данных
• Connection pooling | Database Team | Q2 2024 |
+| **Service Dependencies** | Каскадные сбои при отказе критических сервисов | Средняя | Средний | • Circuit Breaker pattern
• Timeout настройки
• Fallback механизмы
• Health checks | Backend Team | Q1 2024 |
+
+**Бизнес-риски:**
+
+| Риск | Описание | Вероятность | Воздействие | Митигация | Ответственный | Временные рамки |
+|------|----------|-------------|-------------|-----------|---------------|-----------------|
+| **Vendor Lock-in** | Зависимость от конкретных облачных провайдеров | Средняя | Высокий | • Multi-cloud стратегия
• Абстракция инфраструктуры
• Контейнеризация приложений
• Стандартизация API | Architecture Team | Q3 2024 |
+
+##### 2.3.3 Прототипирование критических компонентов
+
+**План прототипирования:**
+
+**Критические компоненты:**
+
+| Компонент | Цель | Область | Временные рамки | Команда | Критерии успеха |
+|-----------|------|---------|-----------------|---------|-----------------|
+| **Payment Integration** | Проверить интеграцию с платежными системами | • Stripe API интеграция
• Обработка webhook'ов
• Обработка ошибок
• Retry механизмы | 2 недели | Backend Team + DevOps | • Успешная обработка тестовых платежей
• Корректная обработка ошибок
• Webhook'и обрабатываются в реальном времени
• Метрики и логирование работают |
+| **Real-time Notifications** | Проверить масштабируемость WebSocket соединений | • WebSocket сервер на Node.js
• Redis для масштабирования
• Load balancing
• Connection management | 1 неделя | Frontend Team + Backend Team | • 1000+ одновременных соединений
• Низкая задержка (< 100ms)
• Автоматическое восстановление соединений
• Мониторинг активных соединений |
+
+**Среда прототипирования:**
+
+| Компонент | Технология |
+|-----------|------------|
+| **Инфраструктура** | Kubernetes cluster (minikube) |
+| **Мониторинг** | Prometheus + Grafana |
+| **Логирование** | ELK Stack |
+| **CI/CD** | GitHub Actions |
+
+**Результаты:**
+
+| Результат | Описание |
+|-----------|----------|
+| **Рабочие прототипы** | Рабочие прототипы критических компонентов |
+| **Отчеты** | Отчеты о производительности |
+| **Рекомендации** | Рекомендации по оптимизации |
+| **Документация** | Обновленная архитектурная документация |
+
+**Архитектурные принципы валидации:**
+
+```mermaid
+flowchart TD
+ A[Валидация архитектуры] --> B[Функциональная валидация]
+ A --> C[Нефункциональная валидация]
+ A --> D[Техническая валидация]
+
+ B --> B1[Покрытие требований]
+ B --> B2[Пользовательские сценарии]
+ B --> B3[Интеграционные тесты]
+
+ C --> C1[Нагрузочное тестирование]
+ C --> C2[Тестирование безопасности]
+ C --> C3[Тестирование отказоустойчивости]
+
+ D --> D1[Code Review]
+ D --> D2[Архитектурные ревью]
+ D --> D3[Прототипирование]
+
+ B1 --> E[Отчет о валидации]
+ B2 --> E
+ B3 --> E
+ C1 --> E
+ C2 --> E
+ C3 --> E
+ D1 --> E
+ D2 --> E
+ D3 --> E
+
+ E --> F[Рекомендации]
+ F --> G[Обновление архитектуры]
+
+ style A fill:#e1f5fe
+ style B fill:#f3e5f5
+ style C fill:#e8f5e8
+ style D fill:#fff3e0
+ style E fill:#fce4ec
+ style F fill:#f1f8e9
+ style G fill:#e0f2f1
+```
### 3. Документирование (Documentation)
@@ -228,14 +939,14 @@ public class RequirementsAnalyzer {
- Количество транзакций в секунду
**Примеры требований:**
-```yaml
-scalability:
- concurrent_users: 10000
- data_volume: "1TB per day"
- transactions_per_second: 1000
- response_time: "< 200ms for 95% of requests"
- availability: "99.9%"
-```
+
+| Параметр | Значение |
+|----------|----------|
+| **Одновременные пользователи** | 10,000 |
+| **Объем данных** | 1TB в день |
+| **Транзакции в секунду** | 1,000 |
+| **Время отклика** | < 200ms для 95% запросов |
+| **Доступность** | 99.9% |
### 2. Надежность (Reliability)
diff --git a/modules/module1/sections/02-introduction-to-software-architecture.md b/modules/module1/sections/02-introduction-to-software-architecture.md
index 8b7a8ac..ec285b5 100644
--- a/modules/module1/sections/02-introduction-to-software-architecture.md
+++ b/modules/module1/sections/02-introduction-to-software-architecture.md
@@ -120,7 +120,15 @@
#### Примеры реализации
-**Java (Spring Boot)**
+