Repository files navigation

1. Придумать систему, состоящую минимум из 4х взаимодействующих друг с другом сервисов. Каждый сервис реализует своюфункциональность и взаимодействует с другими сервисами по протоколу HTTP (придерживаться нотации RESTful), либо черезочередь. Также для межсервисного взаимодействия допускается использовать другие протоколы, например gRPC.
2. Каждый сервис имеет свое собственное хранилище, если оно ему нужно.
3. Выделить отдельный сервис Авторизации (Session Service), который хранит в себе информацию о пользователях ииспользуется для пользовательской авторизации и аутентификации.
4. Для авторизация пользователь отправляет login + password, в ответ получает JWT токен. Токен выдает Session Service,валидация токена выполняется так же на Session Service. Пароли хранить в базе в хэшированном виде.
5. Можно выделить Gateway Service, который будет единой точкой входа в систему. Все запросы (проме получения токена)проходят через него, он выполняет проверку токена в Session Service.
6. Если Gateway Service не используется, то все межсервисные запросы передают токен по цепочке и каждый сервис проверяетего в Session Service.
7. Реализовать пользовательский интерфейс HTML+CSS, желательно SPA (React, Angular, Vue) или мобильный клиент.Использование CSS обязательно.
8. Если есть Gateway Service, то запросы от UI могут быть к только к нему, либо к Session Service для получения токена.
9. Реализовать валидацию входных данных как на front-end’е, так и на back-end’е.
10. Реализовать ролевую модель, создать минимум одного пользователя с ролью Admin и одного пользователя с ролью User.
11. Выделить сервис статистики, туда отправлять через очередь статистику по операциям. В зависимости от задания попришедшим данным строить отчет, доступ к которому должен быть только у пользователя с ролью Admin.
12. Предусмотреть ситуацию недоступности систем, обработку таймаутов и ошибок сервисов. В случае ошибки/недоступностинекритичного функционала выполнять деградацию функциональности.
13. Весь код хранить на GitHub, автоматизировать процесс сборки, тестирования и релиза на внешней платформе. Для CI/CDиспользовать Github Actions.
14. (¹) Развернуть сервисы в Kubernetes Managed кластере, связать его с доменным именем 3 или 4 уровня. Главная страницадолжна открываться по основному имени. Например:
    • UI: aero-ticket.ru
    • Gateway: gw.air-ticket.ru
    • Airport Service: airport.air-ticket.ru
    • Flight Service: flight.air-ticket.ru
    • Ticket Service: ticket.air-ticket.ru
    • Miles Service: miles.air-ticket.ru

¹ – если будет такая возможность.

Если вы выбрали для курсового проекта ту же тему, что и в курсе Технология Программирования, то при написанииТехнического задания нужно учитывать следующее:

Техническое задание является основополагающим документом, по которому ведётся разработка и приёмка работы. Поэтому ТЗдолжно быть максимально четким и полным, не допускать двусмысленную трактовку фраз. Любой невыполненный функционал,описанный в ТЗ, приводит к автоматическому снижению оценки. Следовательно, в ТЗ описываются:

• все требования к курсовой работе; ваш вариант задания (если взят предложенный вариант) или функционал вашей системы,согласованный с преподавателем;
• любой дополнительный и не противоречащий п. 1. и 2. функционал, который Вы уверены на 200%, что реализуете.

Лучше реализовать больше, чем указано в ТЗ, чем наоборот.

Неправильное ТЗ: "Реализовать систему управления полётами".

Правильное ТЗ (задание 2019-2020 уч. года): "Разработать прототип системы поиска объектов туризма и отдыха на базевеб-интерфейса. Система должна состоять из микросервисов, каждый из которых отвечает за свою задачу: сервиспользовательского интерфейса; сервис авторизации и данных пользовательских аккаунтов; сервис объектов туризма и отдыха;сервис тегов; сервис статистики; сервис агрегирования запросов и предоставления ограниченного функционала для стороннихприложений. Каждый сервис при необходимости может иметь доступ к связанной с ним базе данных, но не должен иметь доступак базам данных других сервисов. Все запросы между сервисами требуют авторизацию. Запросы пользователей делятся на двекатегории:запросы, требующие авторизации пользователя, и запросы, доступные для всех пользователей, даже неавторизованных. Всеошибки должны обрабатываться; в случае недоступности некритичного функционала должна осуществляться деградацияфункциональности. Все действия на сервисах должны логироваться. Все сервисы должны собираться и разворачиваться черезCI/CD."

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

РПЗ должна состоять из трех частей:

1. Аналитический раздел. В данном разделе приводится обзор существующих систем описываются основные требования, ксистеме. Здесь же формулируется бизнес-логика будущей системы.
2. Конструкторский раздел. Описание архитектуры и алгоритмов, используемых в системе. Если алгоритм стандартный –достаточно поставить ссылку на него. В этом разделе приводится общая схема системы и описание каждого компонента вотдельности. Обязательно описать выделенные сущности, чем они характеризуются, дать описание ролевой модели, описатьсхему взаимодействия систем с помощью Диаграммы последовательности действий.
3. Технологический раздел. В данном разделе приводится описание типов и структур данных (структура БД), а такжеописываются нюансы реализации. Здесь же надо описать как выполняется сборка и деплой системы. Выбор языка (если этоС#/Java/Python/Go) писать не надо, это информация не несет никакого смысла. Здесь описывается тестирование системы иее поведение в случае отказа компонентов, ее составляющих.

Записка должна быть оформлена по ГОСТ 7.32-2017. В конце обязательно привести список литературы.

ТЗ, написанное в рамках лабораторных работ по курсу Технология программирования, не является РПЗ. Из ТЗ можноиспользовать формальную постановку задачи и требования к системе, их привести в Аналитическом разделе.

Для допуска к защите курсового проекта требуется:

• законченная рабочая программная реализация с выполнением всех пунктов задания;
• согласованные ТЗ и РПЗ;
• код хранящийся на GitHub.

В Электронном Университете предусмотрены модули по выполнению курсового проекта. Требования для сдачи каждого модуля:

• 1 модуль (9 неделя) – выбрана тема, согласованное ТЗ и аналитический раздел РПЗ;
• 2 модуль (12 неделя) – прототип курсовой (выполнено 50% требований к функционалу) и конструкторский раздел РПЗ;
• 3 модуль (15 неделя) – сдача курсового проекта (программа и РПЗ).