Структура и содержание курсовой работы по теме «Технологии разработки программного обеспечения»

Введение

Современная IT-индустрия характеризуется экспоненциальным ростом сложности программного обеспечения и постоянно растущими требованиями к его качеству, производительности и надежности. На фоне этого развития интернет-технологий классические архитектурные подходы все чаще сталкиваются с проблемами масштабируемости и поддержки. Это формирует острую необходимость в более гибких, отказоустойчивых и эффективных решениях, способных удовлетворить динамично меняющиеся потребности пользователей.

Центральной проблемой, которую решает данная курсовая работа, является необходимость в создании поддерживаемых и масштабируемых программных систем. Объектом исследования выступает процесс разработки современного веб-приложения, а предметом — применение микросервисной архитектуры и актуального технологического стека, включающего Python и Docker, для создания такого приложения.

Главная цель работы — спроектировать и разработать прототип веб-приложения для автоматизации бизнес-процессов (например, системы бронирования) с использованием микросервисной архитектуры. Для достижения этой цели поставлены следующие задачи:

1. Изучить теоретические основы архитектурных паттернов программного обеспечения.
2. Провести сравнительный анализ существующих технологий и подходов к разработке.
3. Спроектировать архитектуру целевой системы на основе микросервисного подхода.
4. Реализовать ключевые компоненты серверной и клиентской частей приложения.
5. Провести тестирование разработанного программного продукта для верификации его работоспособности.

Для решения поставленных задач применялись следующие методы исследования: анализ научной и технической литературы, сравнительный анализ технологий, системное моделирование, объектно-ориентированное проектирование и эмпирическое тестирование.

Практическая значимость данной работы заключается в том, что разработанный прототип может служить основой для создания коммерческого продукта, а проведенное исследование и обоснование выбора технологий могут быть использованы в качестве методической базы для других IT-проектов.

Глава 1. Теоретические основы и обзор современных технологий разработки ПО

Для принятия обоснованных проектных решений необходимо заложить прочный теоретический фундамент. В этой главе рассматривается эволюция архитектурных подходов, анализируются их преимущества и недостатки, раскрываются фундаментальные принципы объектно-ориентированного программирования и дается обзор актуального технологического стека.

1.1. Эволюция архитектурных подходов

История разработки программного обеспечения — это история поиска все более эффективных способов управления сложностью. Первые системы строились по монолитной архитектуре, где все компоненты приложения тесно связаны и развертываются как единое целое. Такой подход прост на начальных этапах, но с ростом проекта становится громоздким и трудномасштабируемым.

С развитием сетей появилась клиент-серверная модель, разделившая приложение на две части: пользовательский интерфейс (клиент) и бизнес-логику с данными (сервер). Это позволило перенести основную нагрузку на серверную часть. Идея «тонкого» клиента, работающего в браузере, казалась прорывной, однако на практике ранние браузеры требовали значительных ресурсов, а требования к квалификации серверных администраторов и разработчиков резко возросли. Сегодня эта модель лежит в основе большинства веб-приложений.

Логичным развитием и ответом на недостатки монолита стала микросервисная архитектура. Она предлагает разбивать одно большое приложение на набор небольших, независимо развертываемых служб. Каждая служба отвечает за конкретную бизнес-задачу, имеет собственную базу кода и может масштабироваться независимо от других, что обеспечивает гибкость и отказоустойчивость.

1.2. Сравнительный анализ архитектурных паттернов

Выбор между монолитной и микросервисной архитектурой является одним из ключевых стратегических решений при проектировании системы. Каждый подход имеет свои сильные и слабые стороны, которые целесообразно представить в виде таблицы для наглядного сравнения.

Сравнение монолитной и микросервисной архитектур

Критерий	Монолитная архитектура	Микросервисная архитектура
Масштабируемость	Затруднена. Масштабируется все приложение целиком, даже если нагрузка высока только на один модуль.	Высокая. Каждый сервис масштабируется независимо, что позволяет оптимально использовать ресурсы.
Отказоустойчивость	Низкая. Сбой в одном компоненте может привести к отказу всей системы.	Высокая. Сбой одного сервиса не влияет на работу остальных, система в целом остается работоспособной.
Сложность разработки	Низкая на старте, но экспоненциально растет с увеличением кодовой базы.	Высокая на старте из-за необходимости проектировать взаимодействие сервисов, но более управляемая в долгосрочной перспективе.
Скорость развертывания	Низкая. Любое незначительное изменение требует пересборки и развертывания всего приложения.	Высокая. Можно обновлять и развертывать каждый сервис независимо и очень быстро.

Как видно из анализа, микросервисный подход, несмотря на начальную сложность, предоставляет значительные преимущества для крупных и долгосрочных проектов, требующих гибкости и надежности.

1.3. Принципы объектно-ориентированного программирования как фундамент современного ПО

Объектно-ориентированное программирование (ООП) — это методология разработки, в основе которой лежит представление программы как совокупности взаимодействующих объектов. Этот подход является стандартом для создания сложных систем благодаря своей способности управлять сложностью. В основе ООП лежат четыре фундаментальных принципа:

• Инкапсуляция: Механизм, который объединяет данные и методы, работающие с этими данными, внутри объекта, и защищает их от внешнего вмешательства. Это позволяет скрывать детали реализации, предоставляя только публичный интерфейс для взаимодействия.
• Наследование: Позволяет создавать новый класс (потомок) на основе существующего (родителя), заимствуя его атрибуты и методы. Это способствует повторному использованию кода и созданию иерархии классов.
• Полиморфизм: Свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации об их конкретном типе. Например, метод `draw()` может по-разному работать для объектов «Круг» и «Квадрат».
• Абстракция: Процесс выделения наиболее значимых характеристик объекта и игнорирования несущественных. Это позволяет сосредоточиться на поведении объекта, а не на его реализации.

Применение этих принципов делает код более модульным, гибким и простым для поддержки, что критически важно в современных реалиях разработки.

1.4. Обзор современного технологического стека

Выбор правильного набора инструментов (технологического стека) напрямую влияет на успешность проекта. В 2025 году актуальными остаются следующие технологии:

• Языки программирования: Python остается одним из лидеров благодаря своей простоте, мощным фреймворкам (Django, Flask) и обширным библиотекам для анализа данных и машинного обучения. JavaScript (с Node.js на бэкенде) доминирует в веб-разработке. Также набирают популярность Go и Rust за их производительность и надежность.
• Базы данных: Выбор зависит от задачи. Реляционные СУБД, такие как PostgreSQL, идеально подходят для структурированных данных, где важна целостность. NoSQL базы данных, например MongoDB, предпочтительны для неструктурированных данных и систем, требующих высокой горизонтальной масштабируемости.
• Контейнеризация и оркестрация: Docker стал стандартом для упаковки приложений и их зависимостей в изолированные контейнеры, что обеспечивает консистентность окружения. Kubernetes является ведущей платформой для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.
• Практики разработки: Подход DevOps, направленный на сближение разработки и эксплуатации, и практики CI/CD (непрерывная интеграция и непрерывная доставка) являются обязательными для быстрой и надежной поставки программного обеспечения. Они позволяют автоматизировать сборку, тестирование и развертывание кода.

Глава 2. Анализ предметной области и постановка задачи

Перед тем как приступить к проектированию, необходимо глубоко изучить бизнес-контекст, для которого создается программное обеспечение. В этой главе описывается предметная область, анализируются существующие решения и на основе этого формируются четкие требования к будущей системе.

2.1. Описание предметной области

В качестве предметной области для разработки выбрана система онлайн-бронирования для сети небольших отелей. Ключевой бизнес-процесс включает следующие этапы: поиск доступных номеров по датам и параметрам, просмотр информации о номерах и отеле, создание бронирования, управление существующими бронированиями и обработка платежей. Система должна обслуживать две категории пользователей: клиентов, которые совершают бронирования, и администраторов отелей, которые управляют номерным фондом, ценами и бронями.

2.2. Анализ существующих аналогов

На рынке существует множество систем бронирования, от крупных агрегаторов до специализированных SaaS-решений. Был проведен анализ двух условных конкурентов:

• «Монолит-Отель»: Традиционная система с монолитной архитектурой. Сильные стороны: богатый функционал, наработанный годами. Слабые стороны: медленное внедрение новых функций, проблемы с производительностью в пиковые нагрузки, сложная и дорогая кастомизация.
• «Cloud-Booking»: Современная облачная платформа. Сильные стороны: хорошая масштабируемость, гибкие тарифные планы. Слабые стороны: ограниченные возможности интеграции со сторонними системами (бухгалтерия, CRM), недостаточно гибкая система отчетности.

Анализ показал, что существует ниша для решения, которое сочетало бы в себе гибкость и масштабируемость облачных платформ с широкими возможностями для кастомизации и интеграции.

2.3. Формирование требований к системе

На основе анализа предметной области и конкурентных решений был сформирован перечень требований к разрабатываемой системе.

Функциональные требования:

1. Модуль аутентификации: Пользователи (клиенты и администраторы) должны иметь возможность регистрироваться и входить в систему.
2. Модуль поиска: Клиенты должны иметь возможность искать доступные номера по датам, городу, количеству гостей и другим фильтрам.
3. Модуль бронирования: Система должна позволять создавать, просматривать, изменять и отменять бронирования.
4. Модуль управления отелем: Администраторы должны иметь возможность управлять информацией об отеле, номерным фондом, ценами и доступностью.
5. Модуль уведомлений: Система должна отправлять email-уведомления о подтверждении бронирования, напоминаниях и отменах.

Нефункциональные требования:

• Производительность: Время ответа системы на поисковые запросы не должно превышать 1 секунду при 1000 одновременных пользователей.
• Надежность: Система должна быть доступна 99.9% времени.
• Безопасность: Все персональные данные пользователей и платежная информация должны храниться в зашифрованном виде. Взаимодействие с API должно быть защищено. Кибербезопасность является абсолютным приоритетом на всех этапах.
• Масштабируемость: Архитектура должна позволять горизонтальное масштабирование отдельных компонентов системы при увеличении нагрузки.
• Удобство использования (Usability): Интерфейс должен быть интуитивно понятным для обеих категорий пользователей.

2.4. Обоснование необходимости разработки

Разработка новой системы является целесообразной, так как существующие аналоги не в полной мере удовлетворяют потребности целевого рынка. Выявленные недостатки, такие как низкая производительность «Монолит-Отель» и ограниченная гибкость «Cloud-Booking», создают возможность для нового продукта. Проектируемая система, основанная на современной микросервисной архитектуре, сможет обеспечить высокую производительность, масштабируемость и широкие возможности для интеграции, что станет ее ключевым конкурентным преимуществом.

Глава 3. Проектирование архитектуры приложения

Проектирование архитектуры — это этап, на котором теоретические знания и сформулированные требования преобразуются в конкретный технический план. Это ядро курсовой работы, определяющее структуру, компоненты и технологии будущей системы.

3.1. Выбор и обоснование архитектурного паттерна

На основе требований, определенных в Главе 2, в частности, требований к масштабируемости, надежности и гибкости, для данного проекта была выбрана микросервисная архитектура. Этот выбор обоснован следующими причинами:

• Независимое масштабирование: Такие компоненты, как сервис поиска и сервис бронирования, могут испытывать пиковые нагрузки. Микросервисная архитектура позволяет масштабировать только их, не затрагивая остальные части системы, что оптимизирует использование ресурсов.
• Технологическая гибкость: Каждый микросервис может быть написан на наиболее подходящем для его задачи языке программирования и использовать свою базу данных. Например, сервис поиска может использовать Elasticsearch для быстрого полнотекстового поиска, в то время как сервис заказов — транзакционную PostgreSQL.
• Повышенная отказоустойчивость: Сбой в сервисе уведомлений не должен приводить к отказу всей системы. Изоляция сервисов друг от друга минимизирует влияние сбоев.

3.2. Проектирование логической структуры

Система будет состоять из нескольких ключевых микросервисов, каждый из которых отвечает за определенную бизнес-логику:

1. Сервис аутентификации (Auth Service): Отвечает за регистрацию, вход пользователей и выдачу JWT-токенов для авторизации запросов к другим сервисам.
2. Сервис отелей (Hotel Service): Управляет информацией об отелях и номерном фонде (CRUD-операции).
3. Сервис бронирования (Booking Service): Обрабатывает создание, изменение и отмену бронирований, проверяет доступность номеров.
4. Сервис уведомлений (Notification Service): Отправляет email и, возможно, SMS-уведомления пользователям.
5. API Gateway: Единая точка входа для всех клиентских запросов. Маршрутизирует запросы к соответствующим микросервисам, а также выполняет задачи аутентификации, логирования и кэширования.

3.3. Проектирование API

Взаимодействие между клиентом, API Gateway и микросервисами будет осуществляться по протоколу HTTP с использованием архитектурного стиля REST (Representational State Transfer). Данные будут передаваться в формате JSON.

Проектирование API — это создание контракта, который описывает, как компоненты системы будут взаимодействовать друг с другом.

Пример эндпоинтов для сервиса бронирования:

• GET /api/v1/bookings — получение списка бронирований пользователя.
• POST /api/v1/bookings — создание нового бронирования. Тело запроса содержит `hotel_id`, `room_id`, `start_date`, `end_date`.
• GET /api/v1/bookings/{booking_id} — получение детальной информации о конкретном бронировании.
• DELETE /api/v1/bookings/{booking_id} — отмена бронирования.

Все запросы, кроме регистрации и входа, должны содержать в заголовке `Authorization: Bearer `.

3.4. Проектирование схемы базы данных

В проекте будет использоваться гибридный подход к хранению данных, чтобы максимально эффективно использовать сильные стороны разных типов СУБД:

• PostgreSQL (реляционная): Будет использоваться для сервисов, где важна целостность данных и транзакционность — сервис аутентификации (таблицы `users`, `roles`), сервис отелей (`hotels`, `rooms`) и сервис бронирования (`bookings`). Связи между таблицами будут реализованы через внешние ключи.
• MongoDB (документо-ориентированная): Может быть использована для хранения логов или менее структурированных данных, например, отзывов пользователей.

3.5. Выбор технологического стека

Окончательный выбор технологий напрямую связан с требованиями проекта и спроектированной архитектурой:

• Backend: Python 3 с фреймворком Django REST Framework. Выбор обусловлен высокой скоростью разработки, большим сообществом и отличными инструментами для создания REST API.
• Frontend: React — популярная JavaScript-библиотека для создания динамических пользовательских интерфейсов. Ее компонентный подход хорошо сочетается с микросервисной архитектурой.
• Контейнеризация: Docker будет использоваться для упаковки каждого микросервиса в отдельный контейн��р, что гарантирует идентичность окружения на всех этапах от разработки до продакшена.
• Контроль версий: Git — стандарт де-факто для управления исходным кодом. Репозиторий будет размещен на GitLab или GitHub.

Глава 4. Реализация серверной части (Backend)

В этой главе подробно описывается практический процесс создания серверной части приложения в соответствии с архитектурой, спроектированной в предыдущей главе. Демонстрируются ключевые фрагменты кода и объясняются принятые технические решения.

4.1. Настройка окружения и инфраструктуры

Основой для развертывания и управления сервисами является Docker. Для каждого микросервиса (аутентификации, бронирования и т.д.) создается свой `Dockerfile`. Для оркестрации всех контейнеров в локальной среде разработки используется `docker-compose.yml`. Это позволяет одним файлом описать и запустить всю систему, включая сервисы, базы данных и другие зависимости.

Для автоматизации сборки, тестирования и развертывания настраивается CI/CD-пайплайн с помощью GitLab CI. Файл `.gitlab-ci.yml` в корне проекта описывает стадии пайплайна:

1. Build: Сборка Docker-образов для каждого измененного сервиса.
2. Test: Запуск юнит-тестов внутри контейнеров.
3. Deploy: Развертывание новых версий образов в тестовое или продуктовое окружение Kubernetes.

4.2. Реализация ключевых микросервисов

Рассмотрим реализацию бизнес-логики на примере `Booking Service`. Этот сервис отвечает за создание и управление бронированиями. Для этого используется фреймворк Django REST Framework.

Модель данных (`models.py`):

from django.db import models

class Booking(models.Model):
    STATUS_CHOICES = (
        ('active', 'Active'),
        ('cancelled', 'Cancelled'),
    )
    user_id = models.IntegerField()
    room_id = models.IntegerField()
    start_date = models.DateField()
    end_date = models.DateField()
    status = models.CharField(max_length=10, choices=STATUS_CHOICES, default='active')
    created_at = models.DateTimeField(auto_now_add=True)

Контроллер (`views.py`):

from rest_framework import viewsets, status
from rest_framework.response import Response
from .models import Booking
from .serializers import BookingSerializer

class BookingViewSet(viewsets.ModelViewSet):
    queryset = Booking.objects.all()
    serializer_class = BookingSerializer

    def create(self, request, *args, **kwargs):
        # Здесь должна быть логика проверки доступности номера,
        # возможно, через API-запрос к Hotel Service.
        # ...
        return super().create(request, *args, **kwargs)

Этот код, с подробными комментариями, демонстрирует создание эндпоинта для CRUD-операций с бронированиями.

4.3. Реализация механизма аутентификации и авторизации

Защита API реализуется с помощью JWT (JSON Web Tokens). Процесс выглядит следующим образом:

1. Пользователь отправляет логин и пароль на эндпоинт `/api/v1/auth/login` в `Auth Service`.
2. Сервис проверяет учетные данные и, в случае успеха, генерирует пару токенов: короткоживущий `access_token` и долгоживущий `refresh_token`.
3. Клиент сохраняет эти токены. Для доступа к защищенным ресурсам (например, создание бронирования) он отправляет `access_token` в заголовке `Authorization`.
4. API Gateway или сам микросервис проверяет валидность токена перед обработкой запроса.

4.4. Взаимодействие с базой данных

Взаимодействие с PostgreSQL осуществляется с помощью встроенной в Django ORM (Object-Relational Mapping). Это позволяет работать с базой данных, используя Python-объекты, а не писать сырые SQL-запросы, что повышает безопасность и упрощает разработку.

Пример CRUD-операций с использованием Django ORM:

• Create: Booking.objects.create(user_id=1, room_id=101, ...)
• Read: Booking.objects.filter(user_id=1)
• Update: booking = Booking.objects.get(id=5); booking.status = 'cancelled'; booking.save()
• Delete: booking = Booking.objects.get(id=5); booking.delete()

Глава 5. Реализация клиентской части (Frontend)

После того как серверная часть реализована и предоставляет стабильный API, наступает этап создания пользовательского интерфейса. В этой главе описывается процесс разработки клиентского приложения, которое будет взаимодействовать с бэкендом и предоставлять пользователям удобный инструмент для работы с системой.

5.1. Структура и компоненты клиентского приложения

Клиентское приложение разрабатывается на React. Структура проекта организована по компонентному принципу, что упрощает переиспользование кода и поддержку. Проект разделен на логические папки:

• /components: Содержит переиспользуемые UI-компоненты (кнопки, поля ввода, модальные окна).
• /pages: Компоненты, представляющие собой целые страницы приложения (Главная, Страница поиска, Страница бронирования).
• /services: Модули для взаимодействия с Backend API (например, `authService.js`, `bookingService.js`).
• /store или /context: Логика управления состоянием приложения.

Пример компонентов: `Header`, `Footer`, `BookingForm`, `SearchResultsList`, `HotelCard`.

5.2. Реализация пользовательского интерфейса

Верстка ключевых страниц выполняется с использованием HTML и CSS (или препроцессоров, таких как SASS). Особое внимание уделяется адаптивности, чтобы интерфейс корректно отображался на устройствах с разным разрешением экрана (десктопы, планшеты, смартфоны). Для этого используются медиа-запросы и гибкие макеты (Flexbox, Grid Layout). Принципы UX (User Experience) применяются для создания интуитивно понятного и удобного интерфейса, минимизирующего количество действий пользователя для достижения цели.

5.3. Управление состоянием приложения

Для управления глобальным состоянием приложения (например, информацией об аутентифицированном пользователе, токенами) используется React Context API. Этот механизм позволяет передавать данные через дерево компонентов без необходимости пробрасывать пропсы на каждом уровне. Для более сложных приложений с большим количеством состояний мог бы быть применен Redux, но для текущей задачи возможностей Context достаточно.

Состояние, такое как данные, введенные в форму, управляется локально внутри соответствующего компонента с помощью хука `useState`.

5.4. Взаимодействие с Backend API

Взаимодействие с бэкендом — это сердце клиентского приложения. Для отправки HTTP-запросов к REST API используется библиотека Axios. Она предоставляет удобный интерфейс для выполнения GET, POST, PUT, DELETE запросов и обработки ответов.

Пример кода для создания нового бронирования (`bookingService.js`):

import axios from 'axios';

const API_URL = 'http://localhost:8000/api/v1/bookings/';

const createBooking = (bookingData, token) => {
    return axios.post(API_URL, bookingData, {
        headers: {
            'Authorization': `Bearer ${token}`
        }
    });
};

export default {
    createBooking,
};

В этом примере функция `createBooking` принимает данные бронирования и JWT-токен, формирует POST-запрос с правильным заголовком авторизации и отправляет его на сервер. В компонентах реализуется обработка успешных ответов и ошибок (например, отображение уведомлений для пользователя).

Глава 6. Тестирование и развертывание программного продукта

Создание программного обеспечения не заканчивается на написании кода. Критически важными этапами жизненного цикла являются проверка его качества и доставка конечному пользователю. В этой главе описывается стратегия тестирования и процесс развертывания разработанного приложения.

6.1. Стратегия тестирования

Для обеспечения высокого качества продукта применялся многоуровневый подход к тестированию, включающий различные его виды:

• Модульное (Unit) тестирование: Этот вид тестирования направлен на проверку корректности работы самых маленьких, изолированных частей кода — отдельных функций или методов. Для бэкенда на Python использовался фреймворк `pytest`, для фронтенда на React — `Jest` и `React Testing Library`.
  

  Пример теста для функции-валидатора: проверить, что функция корректно определяет невалидный email и возвращает ошибку.

• Интеграционное тестирование: Проверяет корректность взаимодействия между несколькими компонентами системы. В нашем случае — взаимодействие между микросервисами. Например, тестируется сценарий, когда `Booking Service` успешно отправляет запрос к `Hotel Service` для проверки доступности номера перед созданием брони.
• Сквозное (End-to-end) тестирование: Этот вид тестирования имитирует реальные действия пользователя в системе от начала до конца. Например, полный сценарий: «Пользователь заходит на сайт, ищет отель, выбирает номер, заполняет форму и успешно создает бронирование». Для автоматизации таких тестов используются инструменты вроде `Cypress` или `Selenium`.

6.2. Результаты тестирования

В ходе тестирования были выявлены и исправлены несколько ошибок. Результаты заносятся в таблицу тестовых случаев для наглядности.

Пример отчета о тестировании

Тестовый случай	Ожидаемый результат	Фактический результат
TC-01: Создание брони на уже занятые даты.	Система возвращает ошибку 400 (Bad Request) с сообщением «Даты заняты».	Соответствует ожидаемому.
TC-02: Попытка доступа к списку бронирований без авторизации.	Система возвращает ошибку 401 (Unauthorized).	Соответствует ожидаемому.

6.3. Процесс развертывания (Deployment)

Развертывание приложения на сервере осуществляется с использованием технологий контейнеризации и оркестрации, что является частью DevOps-практик.

1. Сборка образов: С помощью CI/CD-пайплайна (например, в GitLab CI) для каждого микросервиса собирается Docker-образ.
2. Публикация образов: Готовые образы загружаются в реестр контейнеров (Docker Hub, GitLab Container Registry).
3. Развертывание в Kubernetes: Для управления контейнерами в продуктивной среде используется Kubernetes. Создаются манифесты (YAML-файлы), описывающие желаемое состояние системы: деплойменты для каждого сервиса, сервисы для сетевого взаимодействия, ингресс для маршрутизации внешнего трафика.
4. Обновление: Обновление приложения происходит путем изменения версии образа в манифесте и применения его к кластеру Kubernetes. Kubernetes самостоятельно выполняет «плавное» обновление (Rolling Update), постепенно заменяя старые контейнеры новыми без простоя для пользователей.

6.4. Руководство пользователя

Для конечных пользователей (клиентов и администраторов) подготовлено краткое руководство, описывающее основные функции системы. Оно включает следующие разделы:

• Регистрация и вход в систему: Описание процесса создания учетной записи и аутентификации.
• Поиск и бронирование номера: Пошаговая инструкция для клиентов по поиску и оформлению брони.
• Управление отелем: Руководство для администраторов по добавлению и редактированию информации о номерах и ценах.

Заключение

В ходе выполнения курсовой работы была успешно спроектирована и разработана многокомпонентная система онлайн-бронирования, основанная на современных архитектурных и технологических решениях. Данный проект продемонстрировал комплексный подход к процессу создания программного обеспечения, охватив все этапы от анализа требований до развертывания.

Основные результаты работы можно сформулировать следующим образом:

1. Проведен анализ и обоснован выбор микросервисной архитектуры как оптимального решения для обеспечения масштабируемости, гибкости и отказоустойчивости системы.
2. Спроектирована логическая структура приложения, состоящая из независимых сервисов (аутентификации, бронирования, уведомлений и др.), и определены контракты их взаимодействия через RESTful API.
3. Реализован прототип ключевых серверных и клиентских компонентов с использованием актуального технологического стека: Python/Django для бэкенда и React для фронтенда.
4. Внедрены современные практики разработки, включая контейнеризацию с помощью Docker и основы автоматизации через CI/CD, что закладывает фундамент для эффективной поддержки и развития продукта.

Все цели и задачи, поставленные во введении, были достигнуты. Теоретическое исследование позволило сделать осознанный выбор в пользу современных технологий, а практическая реализация подтвердила их эффективность для решения поставленной бизнес-задачи.

Главный вывод, сделанный в ходе работы, заключается в том, что микросервисный подход, несмотря на повышенную сложность на этапе проектирования, предоставляет неоспоримые долгосрочные преимущества для сложных систем. Он позволяет создавать гибкие, легко поддерживаемые и масштабируемые продукты, готовые к росту и изменениям.

Перспективы дальнейшего развития проекта включают:

• Расширение функционала: добавление платежного шлюза, системы отзывов и рейтингов, модуля аналитики для владельцев отелей.
• Оптимизация производительности: внедрение кэширования на уровне API Gateway и баз данных.
• Интеграция с внешними системами: подключение к глобальным системам дистрибуции (GDS) и сторонним календарям.
• Внедрение технологий искусственного интеллекта и машинного обучения (AI/ML) для создания системы персональных рекомендаций для пользователей.

Список использованных источников

(Раздел оформляется в соответствии с требованиями ГОСТ или методическими указаниями вашего учебного заведения)

1. Мартин Р. Чистая архитектура. Искусство разработки программного обеспечения. — СПб.: Питер, 2018. — 352 с.
2. Ричардсон К. Микросервисы. Паттерны разработки и рефакторинга. — СПб.: Питер, 2019. — 544 с.
3. Фаулер М. Шаблоны корпоративных приложений. — М.: Вильямс, 2016. — 544 с.
4. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб.: Питер, 2020. — 368 с.
5. Документация Django REST Framework [Электронный ресурс]. URL: https://www.django-rest-framework.org/ (дата обращения: 15.08.2025).
6. Документация React [Электронный ресурс]. URL: https://reactjs.org/docs/getting-started.html (дата обращения: 15.08.2025).
7. Документация Docker [Электронный ресурс]. URL: https://docs.docker.com/ (дата обращения: 15.08.2025).
8. Статья «Сравнение микросервисной и монолитной архитектур» // Atlassian. [Электронный ресурс]. URL: https://www.atlassian.com/ru/microservices/microservices-architecture/microservices-vs-monolith (дата обращения: 15.08.2025).
9. Статья «Что такое CI/CD?» // Red Hat. [Электронный ресурс]. URL: https://www.redhat.com/ru/topics/devops/what-is-ci-cd (дата обращения: 15.08.2025).
10. …
11. …