diff --git a/modules/module1/sections/05-architectural-styles-patterns.md b/modules/module1/sections/05-architectural-styles-patterns.md
index 9ccb052..a71667b 100644
--- a/modules/module1/sections/05-architectural-styles-patterns.md
+++ b/modules/module1/sections/05-architectural-styles-patterns.md
@@ -9,7 +9,50 @@
 ## Монолитная архитектура
 
 ### Определение
-**Монолитная архитектура** — это архитектурный стиль, при котором все компоненты приложения объединены в единое развертываемое приложение.
+**Монолитная архитектура** — это архитектурный стиль, при котором все компоненты приложения объединены в единое развертываемое приложение. Это традиционный подход к разработке программного обеспечения, где все функциональные возможности реализованы в рамках одного процесса.
+
+### Принципы работы
+
+#### 1. **Единый процесс**
+- Все компоненты выполняются в рамках одного процесса операционной системы
+- Общая память и ресурсы для всех модулей
+- Простая отладка и профилирование
+
+#### 2. **Совместное развертывание**
+- Все изменения развертываются одновременно
+- Единый артефакт (JAR, WAR, EXE файл)
+- Простота управления версиями
+
+#### 3. **Прямое взаимодействие**
+- Компоненты вызывают друг друга через прямые ссылки
+- Нет сетевых задержек между модулями
+- Высокая производительность внутренних вызовов
+
+#### 4. **Общие ресурсы**
+- Единая база данных для всех модулей
+- Общие библиотеки и зависимости
+- Централизованное управление конфигурацией
+
+### Состав архитектуры
+
+#### **Структурные компоненты:**
+1. **Презентационный слой** — пользовательский интерфейс (UI/API)
+2. **Бизнес-логика** — основная логика приложения
+3. **Слой данных** — работа с базой данных
+4. **Общие утилиты** — вспомогательные функции
+
+#### **Технические компоненты:**
+- **Веб-сервер** — обработка HTTP-запросов
+- **Контейнер приложения** — управление жизненным циклом
+- **ORM/DAO** — работа с базой данных
+- **Кэш** — хранение часто используемых данных
+- **Логирование** — запись событий и ошибок
+
+#### **Инфраструктурные компоненты:**
+- **База данных** — хранение данных
+- **Файловая система** — хранение файлов
+- **Внешние API** — интеграция с внешними сервисами
+- **Мониторинг** — отслеживание состояния приложения
 
 ### Характеристики
 - **Единое развертывание** — все компоненты развертываются вместе
@@ -213,7 +256,55 @@ async def create_order(request: CreateOrderRequest):
 ## Микросервисная архитектура
 
 ### Определение
-**Микросервисная архитектура** — это архитектурный стиль, при котором приложение разбивается на множество небольших, независимых сервисов.
+**Микросервисная архитектура** — это архитектурный стиль, при котором приложение разбивается на множество небольших, независимых сервисов. Каждый сервис отвечает за определенную бизнес-функцию и может быть разработан, развернут и масштабирован независимо от других сервисов.
+
+### Принципы работы
+
+#### 1. **Декомпозиция по бизнес-функциям**
+- Каждый сервис отвечает за одну бизнес-функцию
+- Сервисы организованы вокруг доменных границ
+- Минимизация связанности между сервисами
+
+#### 2. **Независимость сервисов**
+- Каждый сервис имеет собственный жизненный цикл
+- Независимое развертывание и масштабирование
+- Собственная база данных и технологии
+
+#### 3. **Децентрализованное управление**
+- Каждая команда отвечает за свои сервисы
+- Разные технологии и подходы к разработке
+- Децентрализованные данные и управление
+
+#### 4. **Отказоустойчивость**
+- Сервисы должны быть устойчивы к сбоям других сервисов
+- Circuit Breaker и retry механизмы
+- Graceful degradation при недоступности зависимостей
+
+### Состав архитектуры
+
+#### **Основные компоненты:**
+1. **Микросервисы** — независимые сервисы с собственной логикой
+2. **API Gateway** — единая точка входа для клиентов
+3. **Service Discovery** — механизм поиска и регистрации сервисов
+4. **Load Balancer** — распределение нагрузки между экземплярами
+
+#### **Инфраструктурные компоненты:**
+- **Контейнерная платформа** — Docker, Kubernetes
+- **Оркестратор** — управление жизненным циклом сервисов
+- **Мониторинг** — отслеживание состояния сервисов
+- **Логирование** — централизованный сбор логов
+
+#### **Паттерны взаимодействия:**
+- **Синхронное взаимодействие** — REST, GraphQL, gRPC
+- **Асинхронное взаимодействие** — Message Queues, Event Streaming
+- **Saga Pattern** — управление распределенными транзакциями
+- **CQRS** — разделение команд и запросов
+
+#### **Качество и надежность:**
+- **Circuit Breaker** — защита от каскадных сбоев
+- **Bulkhead** — изоляция ресурсов
+- **Timeout** — ограничение времени выполнения
+- **Retry** — повторные попытки при сбоях
 
 ### Характеристики
 - **Независимые сервисы** — каждый сервис работает автономно
@@ -441,7 +532,55 @@ async def create_order(request: CreateOrderRequest):
 ## Event-Driven Architecture (EDA)
 
 ### Определение
-**Event-Driven Architecture** — это архитектурный стиль, основанный на производстве, обнаружении, потреблении и реакции на события.
+**Event-Driven Architecture** — это архитектурный стиль, основанный на производстве, обнаружении, потреблении и реакции на события. Система реагирует на события, которые происходят в реальном времени, обеспечивая слабую связанность и высокую отзывчивость.
+
+### Принципы работы
+
+#### 1. **События как первоклассные объекты**
+- События представляют факты, которые произошли в системе
+- События неизменяемы и содержат всю необходимую информацию
+- События имеют временную метку и уникальный идентификатор
+
+#### 2. **Асинхронная обработка**
+- События обрабатываются асинхронно
+- Отправитель не ждет обработки события получателем
+- Высокая производительность и отзывчивость системы
+
+#### 3. **Слабая связанность**
+- Компоненты не знают друг о друге напрямую
+- Взаимодействие происходит только через события
+- Легкость изменения и расширения системы
+
+#### 4. **Eventual Consistency**
+- Система стремится к консистентности в конечном итоге
+- Временная несогласованность допустима
+- Компенсирующие действия для восстановления консистентности
+
+### Состав архитектуры
+
+#### **Основные компоненты:**
+1. **Event Producers** — компоненты, генерирующие события
+2. **Event Store** — хранилище событий (Event Sourcing)
+3. **Event Bus/Message Broker** — транспорт для событий
+4. **Event Consumers** — компоненты, обрабатывающие события
+
+#### **Паттерны обработки событий:**
+- **Simple Event Processing** — прямая обработка событий
+- **Stream Processing** — обработка потоков событий
+- **Complex Event Processing** — анализ сложных паттернов событий
+- **Event Sourcing** — хранение состояния как последовательности событий
+
+#### **Технологические компоненты:**
+- **Message Brokers** — Apache Kafka, RabbitMQ, AWS SQS
+- **Event Streaming** — Apache Kafka Streams, Apache Pulsar
+- **Event Store** — EventStore, Apache Kafka
+- **Processing Engines** — Apache Storm, Apache Flink
+
+#### **Паттерны интеграции:**
+- **Event Notification** — уведомление о произошедших событиях
+- **Event-Carried State Transfer** — передача состояния через события
+- **Event Sourcing** — восстановление состояния из событий
+- **CQRS** — разделение команд и запросов с событиями
 
 ### Характеристики
 - **События** — значимые изменения в системе
@@ -745,7 +884,65 @@ event_publisher.subscribe(event_handler)
 ## CQRS (Command Query Responsibility Segregation)
 
 ### Определение
-**CQRS** — это паттерн, который разделяет операции чтения и записи данных на разные модели.
+**CQRS** — это паттерн, который разделяет операции чтения и записи данных на разные модели. Это позволяет оптимизировать каждую сторону независимо, обеспечивая лучшую производительность и масштабируемость.
+
+### Принципы работы
+
+#### 1. **Разделение ответственности**
+- **Commands** — операции изменения состояния (Create, Update, Delete)
+- **Queries** — операции чтения данных (Read, Search, Report)
+- Разные модели для разных операций
+- Специализированные обработчики для каждого типа
+
+#### 2. **Оптимизация моделей**
+- **Write Model** — нормализованная структура для консистентности
+- **Read Model** — денормализованная структура для производительности
+- Разные схемы баз данных для чтения и записи
+- Специализированные индексы и структуры данных
+
+#### 3. **Асинхронная синхронизация**
+- Изменения в Write Model асинхронно синхронизируются с Read Model
+- Event-driven обновление Read Model
+- Eventual consistency между моделями
+- Компенсирующие действия при сбоях синхронизации
+
+#### 4. **Независимое масштабирование**
+- Write и Read стороны масштабируются независимо
+- Разные технологии для разных задач
+- Оптимизация ресурсов под конкретные нагрузки
+- Горизонтальное масштабирование каждой стороны
+
+### Состав архитектуры
+
+#### **Основные компоненты:**
+1. **Command Side** — обработка команд изменения данных
+2. **Query Side** — обработка запросов чтения данных
+3. **Event Bus** — синхронизация между сторонами
+4. **Projection Handlers** — обновление Read Model
+
+#### **Command Side компоненты:**
+- **Command Handlers** — обработчики команд
+- **Domain Models** — бизнес-логика и валидация
+- **Write Database** — основное хранилище данных
+- **Event Store** — хранение событий изменений
+
+#### **Query Side компоненты:**
+- **Query Handlers** — обработчики запросов
+- **Read Models** — оптимизированные модели для чтения
+- **Read Database** — специализированные хранилища
+- **Caching Layer** — кэширование часто запрашиваемых данных
+
+#### **Синхронизация:**
+- **Event Publishers** — публикация событий изменений
+- **Event Subscribers** — подписка на события
+- **Projection Services** — обновление Read Model
+- **Reconciliation** — восстановление консистентности
+
+#### **Технологические решения:**
+- **Message Brokers** — Apache Kafka, RabbitMQ для событий
+- **Databases** — PostgreSQL для Write, MongoDB для Read
+- **Caching** — Redis для кэширования Read Model
+- **Search Engines** — Elasticsearch для сложных запросов
 
 ### Характеристики
 - **Разделение команд и запросов** — разные модели для записи и чтения
@@ -1042,7 +1239,72 @@ class OrderQueryHandler:
 ## Hexagonal Architecture (Ports and Adapters)
 
 ### Определение
-**Hexagonal Architecture** — это архитектурный паттерн, который изолирует бизнес-логику от внешних зависимостей.
+**Hexagonal Architecture** — это архитектурный паттерн, который изолирует бизнес-логику от внешних зависимостей. Также известен как "Ports and Adapters" или "Clean Architecture", он обеспечивает независимость бизнес-логики от внешних технологий и инфраструктуры.
+
+### Принципы работы
+
+#### 1. **Изоляция бизнес-логики**
+- Бизнес-логика находится в центре архитектуры
+- Не зависит от внешних технологий и фреймворков
+- Чистые доменные модели без внешних зависимостей
+- Легкость тестирования и изменения
+
+#### 2. **Порты и адаптеры**
+- **Порты** — интерфейсы, определяющие контракты взаимодействия
+- **Адаптеры** — реализации портов для конкретных технологий
+- Инверсия зависимостей — бизнес-логика определяет интерфейсы
+- Внешние компоненты реализуют эти интерфейсы
+
+#### 3. **Направление зависимостей**
+- Зависимости направлены внутрь, к бизнес-логике
+- Внешние слои зависят от внутренних
+- Бизнес-логика не знает о внешних технологиях
+- Легкость замены внешних компонентов
+
+#### 4. **Тестируемость**
+- Бизнес-логика тестируется изолированно
+- Mock-объекты для внешних зависимостей
+- Unit-тесты без внешних ресурсов
+- Интеграционные тесты с реальными адаптерами
+
+### Состав архитектуры
+
+#### **Структурные слои:**
+1. **Domain Layer** — бизнес-логика и доменные модели
+2. **Application Layer** — координация бизнес-операций
+3. **Infrastructure Layer** — внешние зависимости и технологии
+4. **Presentation Layer** — пользовательский интерфейс
+
+#### **Domain Layer компоненты:**
+- **Entities** — основные бизнес-объекты
+- **Value Objects** — неизменяемые объекты
+- **Domain Services** — бизнес-логика, не принадлежащая сущностям
+- **Domain Events** — события домена
+- **Repositories (Ports)** — интерфейсы для работы с данными
+
+#### **Application Layer компоненты:**
+- **Use Cases** — координация бизнес-операций
+- **Application Services** — оркестрация доменных объектов
+- **Command/Query Handlers** — обработка команд и запросов
+- **Ports** — интерфейсы для внешних сервисов
+
+#### **Infrastructure Layer компоненты:**
+- **Repository Implementations** — реализация репозиториев
+- **External Service Adapters** — адаптеры для внешних API
+- **Database Adapters** — работа с базами данных
+- **Message Queue Adapters** — работа с очередями сообщений
+
+#### **Presentation Layer компоненты:**
+- **Controllers** — обработка HTTP-запросов
+- **View Models** — модели представления
+- **API Adapters** — адаптеры для внешних API
+- **UI Components** — компоненты пользовательского интерфейса
+
+#### **Паттерны интеграции:**
+- **Dependency Injection** — внедрение зависимостей
+- **Factory Pattern** — создание объектов
+- **Observer Pattern** — обработка событий
+- **Strategy Pattern** — выбор алгоритмов
 
 ### Характеристики
 - **Порты** — интерфейсы для взаимодействия с внешним миром
@@ -1527,7 +1789,75 @@ class EmailNotificationService(NotificationService):
 ## Layered Architecture
 
 ### Определение
-**Layered Architecture** — это архитектурный паттерн, который организует код в горизонтальные слои.
+**Layered Architecture** — это архитектурный паттерн, который организует код в горизонтальные слои. Каждый слой имеет определенную ответственность и может взаимодействовать только с соседними слоями, обеспечивая четкое разделение обязанностей и управляемость системы.
+
+### Принципы работы
+
+#### 1. **Разделение ответственности**
+- Каждый слой имеет четко определенную ответственность
+- Слои изолированы друг от друга
+- Изменения в одном слое не влияют на другие
+- Легкость понимания и поддержки кода
+
+#### 2. **Направление зависимостей**
+- Зависимости направлены вниз (к более низким слоям)
+- Высокие слои зависят от низких
+- Низкие слои не знают о высоких
+- Инверсия зависимостей через интерфейсы
+
+#### 3. **Инкапсуляция**
+- Детали реализации скрыты внутри слоя
+- Внешние слои взаимодействуют через интерфейсы
+- Изменения в реализации не влияют на клиентов
+- Легкость замены компонентов
+
+#### 4. **Повторное использование**
+- Низкие слои могут использоваться разными высокими слоями
+- Общая функциональность выносится в отдельные слои
+- Компоненты могут быть переиспользованы
+- Модульность и расширяемость
+
+### Состав архитектуры
+
+#### **Основные слои:**
+
+##### **1. Presentation Layer (Слой представления)**
+- **Ответственность:** Пользовательский интерфейс и взаимодействие
+- **Компоненты:** Controllers, Views, API endpoints, UI components
+- **Технологии:** REST controllers, GraphQL resolvers, Web UI
+- **Взаимодействие:** Получает запросы от пользователей, делегирует обработку Application Layer
+
+##### **2. Application Layer (Слой приложения)**
+- **Ответственность:** Координация бизнес-операций и оркестрация
+- **Компоненты:** Application Services, Use Cases, Command/Query Handlers
+- **Технологии:** Service classes, Transaction management
+- **Взаимодействие:** Координирует работу Domain Layer, управляет транзакциями
+
+##### **3. Domain Layer (Доменный слой)**
+- **Ответственность:** Бизнес-логика и доменные правила
+- **Компоненты:** Entities, Value Objects, Domain Services, Business Rules
+- **Технологии:** Domain models, Business logic
+- **Взаимодействие:** Содержит основную бизнес-логику, не зависит от внешних слоев
+
+##### **4. Infrastructure Layer (Инфраструктурный слой)**
+- **Ответственность:** Внешние зависимости и техническая реализация
+- **Компоненты:** Repositories, External APIs, Database, File System
+- **Технологии:** ORM, HTTP clients, Database drivers
+- **Взаимодействие:** Реализует интерфейсы, определенные в Domain Layer
+
+#### **Дополнительные слои:**
+
+##### **Cross-Cutting Concerns (Сквозные аспекты)**
+- **Логирование** — запись событий и ошибок
+- **Безопасность** — аутентификация и авторизация
+- **Кэширование** — хранение часто используемых данных
+- **Мониторинг** — отслеживание производительности
+
+##### **Integration Layer (Слой интеграции)**
+- **Внешние API** — интеграция с внешними сервисами
+- **Message Queues** — асинхронная обработка сообщений
+- **Event Handlers** — обработка внешних событий
+- **Data Transformation** — преобразование данных между системами
 
 ### Слои
 1. **Presentation Layer** — пользовательский интерфейс
@@ -1902,7 +2232,92 @@ def get_order_service() -> OrderApplicationService:
 ## Serverless Architecture
 
 ### Определение
-**Serverless Architecture** — это архитектурный стиль, при котором приложение состоит из функций, которые выполняются в ответ на события.
+**Serverless Architecture** — это архитектурный стиль, при котором приложение состоит из функций, которые выполняются в ответ на события. Разработчики не управляют серверами напрямую, а полагаются на облачные провайдеры для управления инфраструктурой, масштабированием и развертыванием.
+
+### Принципы работы
+
+#### 1. **Functions as a Service (FaaS)**
+- Код выполняется в виде отдельных функций
+- Функции запускаются по требованию
+- Автоматическое управление жизненным циклом
+- Изоляция выполнения функций
+
+#### 2. **Event-driven execution**
+- Функции запускаются в ответ на события
+- Различные триггеры: HTTP-запросы, сообщения, файлы, расписания
+- Асинхронная обработка событий
+- Высокая отзывчивость системы
+
+#### 3. **Stateless functions**
+- Функции не сохраняют состояние между вызовами
+- Все данные передаются через параметры
+- Внешние хранилища для персистентности
+- Горизонтальное масштабирование
+
+#### 4. **Pay-per-execution**
+- Оплата только за фактическое выполнение
+- Нет платы за простаивающие ресурсы
+- Экономическая эффективность для переменных нагрузок
+- Автоматическое масштабирование до нуля
+
+### Состав архитектуры
+
+#### **Основные компоненты:**
+
+##### **1. Function Runtime (Среда выполнения функций)**
+- **AWS Lambda** — Amazon Web Services
+- **Azure Functions** — Microsoft Azure
+- **Google Cloud Functions** — Google Cloud Platform
+- **Cloudflare Workers** — Cloudflare
+- **Vercel Functions** — Vercel
+
+##### **2. Event Sources (Источники событий)**
+- **HTTP Triggers** — REST API, Webhooks
+- **Message Queues** — SQS, Service Bus, Pub/Sub
+- **File Storage** — S3, Blob Storage, Cloud Storage
+- **Database Events** — DynamoDB Streams, Cosmos DB
+- **Scheduled Events** — CloudWatch Events, Timer Triggers
+
+##### **3. Backend Services (Backend-сервисы)**
+- **Database as a Service** — DynamoDB, Cosmos DB, Firestore
+- **Storage Services** — S3, Blob Storage, Cloud Storage
+- **Message Services** — SNS, Event Grid, Pub/Sub
+- **Authentication** — Cognito, Azure AD, Firebase Auth
+- **API Gateway** — AWS API Gateway, Azure API Management
+
+#### **Паттерны архитектуры:**
+
+##### **1. Event-Driven Processing**
+- **Event Sourcing** — хранение состояния как событий
+- **CQRS** — разделение команд и запросов
+- **Saga Pattern** — управление распределенными транзакциями
+- **Event Streaming** — обработка потоков событий
+
+##### **2. Microservices Patterns**
+- **Function per Service** — одна функция на сервис
+- **Function per Use Case** — одна функция на use case
+- **Function per Domain** — группировка по доменам
+- **Function Composition** — композиция функций
+
+##### **3. Integration Patterns**
+- **API Gateway** — единая точка входа
+- **Service Mesh** — управление сервисами
+- **Event Bus** — шина событий
+- **Message Routing** — маршрутизация сообщений
+
+#### **Технологические решения:**
+
+##### **Cloud Providers:**
+- **AWS** — Lambda, API Gateway, DynamoDB, S3
+- **Azure** — Functions, Logic Apps, Cosmos DB, Blob Storage
+- **Google Cloud** — Cloud Functions, Cloud Run, Firestore
+- **Multi-cloud** — Serverless Framework, Terraform
+
+##### **Development Tools:**
+- **Frameworks** — Serverless Framework, AWS SAM, Azure Functions Core Tools
+- **Testing** — LocalStack, SAM Local, Azure Functions Core Tools
+- **Monitoring** — CloudWatch, Application Insights, Stackdriver
+- **CI/CD** — GitHub Actions, Azure DevOps, AWS CodePipeline
 
 ### Характеристики
 - **FaaS** — Functions as a Service