- Придумать систему, состоящую минимум из 4х взаимодействующих друг с другом сервисов. Каждый сервис реализует свою функциональность и взаимодействует с другими сервисами по протоколу HTTP (придерживаться нотации RESTful), либо через очередь. Также для межсервисного взаимодействия допускается использовать другие протоколы, например gRPC.
- Каждый сервис имеет свое собственное хранилище, если оно ему нужно.
- Выделить отдельный сервис Авторизации (Session Service), который хранит в себе информацию о пользователях и используется для пользовательской авторизации и аутентификации.
- Для авторизация пользователь отправляет login + password, в ответ получает JWT токен. Токен выдает Session Service, валидация токена выполняется так же на Session Service. Пароли хранить в базе в хэшированном виде.
- Можно выделить Gateway Service, который будет единой точкой входа в систему. Все запросы (проме получения токена) проходят через него, он выполняет проверку токена в Session Service.
- Если Gateway Service не используется, то все межсервисные запросы передают токен по цепочке и каждый сервис проверяет его в Session Service.
- Реализовать пользовательский интерфейс HTML+CSS, желательно SPA (React, Angular, Vue) или мобильный клиент. Использование CSS обязательно.
- Если есть Gateway Service, то запросы от UI могут быть к только к нему, либо к Session Service для получения токена.
- Реализовать валидацию входных данных как на front-end’е, так и на back-end’е.
- Реализовать ролевую модель, создать минимум одного пользователя с ролью Admin и одного пользователя с ролью User.
- Выделить сервис статистики, туда отправлять через очередь статистику по операциям. В зависимости от задания по пришедшим данным строить отчет, доступ к которому должен быть только у пользователя с ролью Admin.
- Предусмотреть ситуацию недоступности систем, обработку таймаутов и ошибок сервисов. В случае ошибки/недоступности некритичного функционала выполнять деградацию функциональности.
- Весь код хранить на GitHub, автоматизировать процесс сборки, тестирования и релиза на внешней платформе. Для CI/CD использовать Github Actions.
- (¹) Развернуть сервисы в 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."
Расчетно-пояснительная записка является документом, описывающим как работает ваша система. Написать ее надо так, как будто вы получаете на поддержку незнакомую систему. Другими словами, любое архитектурное решение, костыль, нетривиальная оптимизация должна иметь пояснение почему сделано именно так.
РПЗ должна состоять из трех частей:
- Аналитический раздел. В данном разделе приводится обзор существующих систем описываются основные требования, к системе. Здесь же формулируется бизнес-логика будущей системы.
- Конструкторский раздел. Описание архитектуры и алгоритмов, используемых в системе. Если алгоритм стандартный – достаточно поставить ссылку на него. В этом разделе приводится общая схема системы и описание каждого компонента в отдельности. Обязательно описать выделенные сущности, чем они характеризуются, дать описание ролевой модели, описать схему взаимодействия систем с помощью Диаграммы последовательности действий.
- Технологический раздел. В данном разделе приводится описание типов и структур данных (структура БД), а также описываются нюансы реализации. Здесь же надо описать как выполняется сборка и деплой системы. Выбор языка (если это С#/Java/Python/Go) писать не надо, это информация не несет никакого смысла. Здесь описывается тестирование системы и ее поведение в случае отказа компонентов, ее составляющих.
Записка должна быть оформлена по ГОСТ 7.32-2017. В конце обязательно привести список литературы.
ТЗ, написанное в рамках лабораторных работ по курсу Технология программирования, не является РПЗ. Из ТЗ можно использовать формальную постановку задачи и требования к системе, их привести в Аналитическом разделе.
Для допуска к защите курсового проекта требуется:
- законченная рабочая программная реализация с выполнением всех пунктов задания;
- согласованные ТЗ и РПЗ;
- код хранящийся на GitHub.
В Электронном Университете предусмотрены модули по выполнению курсового проекта. Требования для сдачи каждого модуля:
- 1 модуль (9 неделя) – выбрана тема, согласованное ТЗ и аналитический раздел РПЗ;
- 2 модуль (12 неделя) – прототип курсовой (выполнено 50% требований к функционалу) и конструкторский раздел РПЗ;
- 3 модуль (15 неделя) – сдача курсового проекта (программа и РПЗ).