Защита итоговых проектов по архитектуре приложений: взгляд изнутри
В 2022 году мы запустили курс Архитектура приложений, на котором учим писать как разработчик, но думать — как архитектор. Этот курс заканчивается важным этапом — защитой итоговых проектов. Принимать в ней участие не обязанность, а возможность продемонстрировать свои новые навыки и получить итоговые комментарии от спикеров курса. Такая защита прошла 23 декабря 2022, поэтому в этой статье мы решили подробнее рассказать, как проходит финальная встреча со спикерами и почему она важна для студентов.
Что такое финальный проект
Он состоит из логически связанных между собой заданий в процессе обучения, которые на выходе складываются в единый проект: от небольшой системы с ограниченной функциональностью реализации целой предметной области. Кроме подобного типа заданий есть и те, которые помогают отработать конкретный навык в каждом модуле.
Зачем нужна итоговая защита
Она дает возможность рассказать о своем учебном проекте и объяснить логику архитектурных решений. Этот навык пригодится в дальнейшей работе, а ревью и полезные рекомендации от наставников позволят развить проект и прокачать стек. Главная задача защиты учебного проекта — усилить ваши знания и навыки в архитектуре приложений.
Взглянем изнутри на защиту итоговых проектов, которая прошла 23 декабря.
Свои финальные проекты защитили 6 человек. Выпускники пообщались с наставниками, задали вопросы, а главное — получили ревью от спикеров курса Архитектура приложений: Senior software engineer Егора Лукьянова и Solution Architect & co-founder в TorrowTechnologies Александра Вагнера.
Егор имеет за плечами более 15 лет опыта в IT. В настоящее время руководит бэкенд-разработкой на Python и отвечает за архитектуру платформы анализа больших данных, самоотверженно развивая культуру осознанного проектирования программного обеспечения.
Александр в IT уже 8+ лет. Сейчас строит с нуля компанию и платформу Torrow, где активно применяет богатый опыт разработки high-load веб-сервисов и приложений, а также обширный стек технологий: .NET Core (C#), TypeScript, MongoDB, ElasticSearch.
Первым свой проект продемонстрировал выпускник Игорь Лютоев — разработчик на Python, который пришел на курс с целью прокачать архитектурные навыки в технических направлениях.
Игорь создал сервис уведомлений, который парсит курс доллара на сайте Московской биржи и раз в час отправляет уведомления по электронной почте. На первом уроке была описана первоначальная структура проекта, схема из 6 блоков: планировщик по расписанию запускает сервисы, один из которых парсит данные, а другой их отправляет.
В процессе обучения проект был описан более подробно по схеме C4: Мосбиржа — Трекер курса USD — Email System — Пользователь. Игорь произвел разбивку по взаимодействию сервисов между собой, далее — по компонентам.
По мере добавления новых вводных проект совершенствовался и расширялся: добавленная гибкость позволила системе быстро реагировать на изменение источников и хранилищ данных. В итоге появилась диаграмма классов; системы и сервисы стали работать с интерфейсами, на которые направлены зависимости и в которых происходят реализации.
При этом сама логика сильно не изменилась, но стала полнее:
планировщик (Scheduler);
задания, которые запускают сбор данных и нотификации;
слой репозитория, сохраняющий данные в БД и отдающий их оттуда же;
ходящие между ними дата-классы, которые передают значения (курс доллара и дату).
Игорь задумался и о том, какие паттерны проектирования можно использовать в системе.
Порождающий паттерн — Строитель. Его можно использовать при создании уведомления для отправки. Разные каналы отправки (электронная почта, мессенджер) предполагают разные реализации; контент и структура при этом остаются общими.
Поведенческий паттерн — Наблюдатель. Полезен, когда разные группы подписчиков необходимо уведомлять о наступлении интересующего их конкретного события (например, изменения курса евро). Каждый подписчик может содержать разную логику событий.
Структурный паттерн — Фасад. Позволяет скрыть сложную логику за понятным интерфейсом. В проекте Игоря интерфейс отправки данных (систему интересуют сообщения и получатели) снаружи, а под капотом — логика работы с электронной почтой.
При прохождении модуля «Чистая архитектура» диаграмма классов была доработана с учетом разбивки классов по компонентам и по удалению границ. Появились отдельные модули для парсеров, репозитория и нотификаций. Модули сгруппированы по отдельной логике, а слои разделены таким образом: основная бизнес-логика на верхнем уровне, логика работы с репозиториями на среднем уровне и конкретные реализации на низшем уровне.
Далее были рассмотрены архитектурные подходы, а также функциональные и нефункциональные требования. Система не может считаться завершенной, пока не реализованы главные требования.
Игорь предположил, что систему можно реализовать через подход CQRS/EventSourcing: отдельные сервисы, которые живут сами по себе, и шина данных (парсер, складывающий данные в Kafka). В подобной очереди могут участвовать и другие сервисы. Еще один предложенный подход к реализации — Layered System (слоистая система), в рамках которой все компоненты разделены по слоям: сервисный слой для реализации конкретной бизнес-логики, слой интеграций с различными сервисами и источниками данных, слой репозиториев для работы с конкретными данными.
Ближе к концу обучения была дополнительно учтена масштабируемость системы. Воркеры для парсинга не нуждаются в масштабировании — только для разделения на источники данных. С шиной сообщений можно поработать для надежности. Точно следует масштабировать отправляющие сообщения воркеры (так как отправителей может быть много) и базу данных для них же.
В заключительной части проекта необходимо было учесть конкретные технологии реализации. Для управления БД можно применить PostgreSQL из-за ее способности работать с объемами данных и простого сегментирования. Для работы планировщика наверняка понадобится очередь. Можно использовать Redis с его pub/sub, но это не надолго; лучше посмотреть в сторону RabbitMQ. Для масштабирования системы стоит сразу двигаться в сторону облачной архитектуры (Kubernetes, Docker и т. д.).
О других проектах
Python-разработчик в X5 Retail Group Андрей Чибизов показал проект по реализации REST API CRUD-операций баз данных. Приложение должно уметь подключаться к разнообразным БД на множестве серверов и предоставлять эндпоинт — операции CRUD к базам данных.
Тимлид и разработчик Евгений Боев продемонстрировал телеграм-бот, который принимает все поступающие к нему файлы и помещает их на Яндекс Диск. Евгений давно хотел поработать с ботами в Telegram, чтобы в дальнейшем реализовать свои идеи в личном проекте.
Выпускница Мария выбрала в качестве финального проекта сервис уведомлений о курсах валют, а ее коллеги по курсу Чоро и Петр рассказали об API для умного дома.
Новый поток курса Архитектура приложений стартует 20 февраля 2023. Присоединяйтесь к курсу и защищайте свои проекты на итоговой встрече!
Ведь как сказал автор курса Егор Лукьянов:»Тема архитектуры бесконечна, обучаться ей можно всю жизнь. Менять работу каждый месяц не получится, а разобраться в новом хочется и нужно. Поэтому послушать про проекты других студентов — круто».
