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)** +
+
+ + + + +
+ +
```java // Монолитная архитектура @@ -184,8 +192,9 @@ public class OrderController { } } ``` - -**Rust (Actix Web)** +
+ +
```rust // Монолитная архитектура @@ -238,8 +247,9 @@ async fn create_order( Ok(web::Json(order)) } ``` - -**Node.js (Fastify)** +
+ +
```javascript // Монолитная архитектура @@ -267,8 +277,9 @@ fastify.post('/api/orders', async (request, reply) => { return order; }); ``` - -**Python (FastAPI)** +
+ +
```python # Монолитная архитектура @@ -299,6 +310,8 @@ async def create_order(request: CreateOrderRequest): order = await order_service.create_order(request) return order ``` +
+
### 2. SQL vs NoSQL @@ -340,7 +353,12 @@ async def create_order(request: CreateOrderRequest): #### Примеры реализации -**Java (Spring Boot + JPA)** +**Выберите язык программирования:** +- [Java (Spring Boot + JPA)](#java-sql) | [Rust (SQLx)](#rust-sql) | [JavaScript (Node.js)](#javascript-sql) | [Python (SQLAlchemy)](#python-sql) + +--- + +### Java (Spring Boot + JPA) {#java-sql} ```java // SQL подход (PostgreSQL) @@ -400,7 +418,7 @@ public class MongoUser { } ``` -**Rust (SQLx + MongoDB)** +### Rust (SQLx) {#rust-sql} ```rust // SQL подход (PostgreSQL) @@ -482,7 +500,7 @@ async fn create_user_with_order( } ``` -**Node.js (pg + Mongoose)** +### JavaScript (Node.js) {#javascript-sql} ```javascript // SQL подход (PostgreSQL) @@ -571,7 +589,7 @@ async function createUserWithOrderMongo(request) { } ``` -**Python (SQLAlchemy + MongoDB)** +### Python (SQLAlchemy) {#python-sql} ```python # SQL подход (PostgreSQL) @@ -687,7 +705,12 @@ def create_user_with_order_mongo(request): #### Примеры реализации -**Java (Spring Boot)** +**Выберите язык программирования:** +- [Java (Spring Boot)](#java-rest) | [Rust (Actix Web)](#rust-rest) | [JavaScript (Node.js)](#javascript-rest) | [Python (FastAPI)](#python-rest) + +--- + +### Java (Spring Boot) {#java-rest} ```java // REST API @@ -716,7 +739,7 @@ public class UserResolver implements GraphQLResolver { } ``` -**Rust (Actix Web + Juniper)** +### Rust (Actix Web) {#rust-rest} ```rust // REST API @@ -753,7 +776,26 @@ const resolvers = { }; ``` -**Python (FastAPI + Strawberry)** +### JavaScript (Node.js) {#javascript-rest} + +```javascript +// REST API +fastify.get('/api/users/:id', async (request, reply) => { + const user = await userService.findById(request.params.id); + return user; +}); + +// GraphQL +const resolvers = { + User: { + orders: async (user) => { + return await orderService.findByUserId(user.id); + } + } +}; +``` + +### Python (FastAPI + Strawberry) {#python-rest} ```python # REST API @@ -969,7 +1011,12 @@ class User: #### Примеры реализации -**Java (Spring Boot + Redis)** +**Выберите язык программирования:** +- [Java (Spring Boot + Redis)](#java-cache) | [Rust (Redis + Tokio)](#rust-cache) | [JavaScript (Node.js + Redis)](#javascript-cache) | [Python (FastAPI + Redis)](#python-cache) + +--- + +### Java (Spring Boot + Redis) {#java-cache} ```java // Cache-Aside Pattern @@ -1025,8 +1072,9 @@ public class UserServiceWriteThrough { } } ``` + -**Rust (Redis + Tokio)** +
```rust // Cache-Aside Pattern @@ -1084,8 +1132,9 @@ impl UserService { } } ``` +
-**Node.js (Redis + ioredis)** +
```javascript // Cache-Aside Pattern @@ -1159,8 +1208,9 @@ class UserServiceWriteBehind { } } ``` +
-**Python (Redis + aioredis)** +
```python # Cache-Aside Pattern @@ -1233,6 +1283,8 @@ class UserService: except Exception as e: print(f"Async save error: {e}") ``` +
+ ## Рекомендации по выбору @@ -1333,3 +1385,86 @@ class UserService: > **💡 Совет**: Документируйте архитектурные решения в Architecture Decision Records (ADR) для будущих поколений разработчиков. + + + + +