📚 Что почитать и посмотреть по REST API: подборка материалов от GetAnalyst 📚

У нас много новых участников в сообществе 🙌 И…! Вместо того, чтобы рассказывать о себе, я решила сделать для вас подборку из полезных материалов по проектированию REST API. Так вы лучше узнаете меня - Екатерину Ананьеву - не на словах, а на деле 🙂

Материалы расположены по порядку - от простого к сложному. Они помогут вам сделать крутой прорыв в освоении темы и разобраться в сложных вопросах.

(В) Связь базы данных и дизайна REST API

(C) Простыми словами про API

(В) Postman: навык тестирования REST API за вечер

(Т) Проект “Система для автосервиса”: полный разбор от проектирования базы данных до дизайна REST API методов.
Ч 1. Проектирование БД
Ч 2. REST API

(В) Проект “Система для автосервиса” - видео-обучение.
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
3. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса

(C) Postman: Практическое руководство с примером тестирования открытого API

(П) Вопросы и ответы по REST API: собеседование на СА

(С) Мини-книга с подробным разбором формата сообщений JSON

(Т) Разбор проекта “Мобильное приложение G-Food для подсчета калорий”

(В) Собеседование на СА: разбор задачи на асинхронные запросы в REST API

(C) Структура постановки задачи на REST API метод

(Т) Разбор проекта по REST API для системы умного дома Smart Home GA

(П) gRPС vs REST - что выбрать для проекта

(C) Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)

(C) Программирование на Python для системных аналитиков: как сделать REST API с нуля

Также вы можете найти у нас мини-обучения по REST API и практическую программу "Дизайн REST API" для опытных аналитиков.

(В) Видео
(П) Подкасты
(С) Статьи
(Т) Серия Telegram-постов с разбором проекта

Делитесь с коллегами, особенно с джунами и мидлами СА!
Сохранили? ❤️

#RestApiGA

🎙 Угадай подкаст 🎙

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

Недавно были эпизоды по gRPC и REST API с разбором вопросов с собеседований, а следующий эпизод совсем вау! Я большой фанат именно технических тем! 💛

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

Готовилась к записи в обстановке любимого кафе. И подумала, что будет круто, если вы попробуете угадать тему по расплывчатым очертаниям букв на фоне пальм, или интуитивно 😉

Давайте включать креативность!

Пишите комментарии под этот пост:
1 + тему предстоящего эпизода,
2 + тему, которую вы хотели бы увидеть в подкасте как можно скорее.

Выбирать буду двух победителей:
1. кто первый наиболее близко угадает тему нового эпизода до релиза,
2. кто предложит ТОП-тему для нового подкаста. За новые темы в комментариях можно голосовать))

В понедельник подведу итоги. Победителям дам доступы к мини-обучениям в записи под индивидуальный запрос, чтобы было актуально именно для вас (БД, REST API, GraphQL, Интеграции, Архитектура или ChatGPT).

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

Всем креативности и идей, жду ваши комментарии 😊

Какая цель? 🎯

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

Вот список ваших целей, которые реально мотивируют на результаты:
◾️Хочется сменить проект, но на текущем месте работы нет возможности получить нужный опыт
◾️Хочу освоить навык, чтобы меня повысили в ЗП
◾️Структурировать знания
◾️Обновить резюме и пополнить его новыми навыками
◾️Освоить новые инструменты

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

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

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

А если вам нужна поддержка, структура, важен срок и вы сейчас думаете о получении опыта в REST API, то до первого онлайн-занятия 6 мая, вы еще можете успеть присоединиться на практическую программу Дизайн REST API.

В течение 2-х месяцев мы будем работать над проектом с нуля до результата: переноса разработанных методов из документации Confluence в интерактивную документацию Postman и Swagger 🤩

Профессиональный рост и интересные проекты начинаются с обучения. Я верю в вас и всегда готова поддержать ❤️

Делайте смелые шаги в своем развитии. Любыми способами! Всё получится! 🚀

📌 Новый проект TelMed: от монолита к микросервисам 📌

Проект "TelMed" - платформа для оказания услуг телемедицины (онлайн приемы к врачу), которая позволит обеспечить удобный и безопасный доступ к медицинским услугам для пациентов вне зависимости от их местоположения.

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

Основная функциональность:

🔸1. ЛК Пациента
Регистрация пациентов. Хранение персональных данных и медицинской истории, включая болезни, диагнозы, лечение, результаты анализов.

🔸2. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, с уведомлением пациентов по всем доступным каналам связи: телефон, почта, push.

🔸3. Учет оборудования для сбора и анализа медицинских показателей
Управление заказом и доставкой дополнительного оборудования. Заказ и доставка на период проведение консультации, в зависимости от вида услуги.

🔸4. Проведение онлайн-консультаций
Защищенная видеосвязь в реальном времени. Чат и возможность обмена документами во время консультации. Интеграция с диагностическими инструментами для сбора и анализа медицинских показателей в реальном времени

🔸5. Аптечные услуги
Создание электронных рецептов. Мониторинг наличия лекарств в партнерской сети аптек, их резервирование или заказ. Управление доставкой лекарств.

🔸6. Анализы
Выдача направлений на анализы. Автоматическое получение результатов.

🔸7. Платежи
Подключение платежной системы.

🔸8. ЛК Врача
Профили врачей и настройка доступного времени для консультаций.

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

Это новый проект. С чего начать?
Если по бизнесу уже разобрались, ФТ и НФТ сделали, то теперь надо определиться с архитектурой. Монолит или микросервисы? Будем разбираться в этих темах и исследовать варианты.

Welcome to the new GetAnalyst project!

#АрхитектураGA #TelMed

🪨 Монолитная архитектура и ее особенности 🪨

Монолитная архитектура – это подход к разработке программного обеспечения, при котором все компоненты приложения объединены в единый и неделимый блок, называемый монолитом.


В такой архитектуре вся функциональность приложения, включая:

+ интерфейс пользователя (UI),
+ базу данных (БД),
+ бизнес-логику (алгоритмы обработки данных),

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


Проще говоря, когда вы ставите задачу на программиста, то вы не задумываетесь о понятиях Backend-Frontend, клиент-сервер, с мобильными приложениями не работаете. Системный аналитик в таких проектах занимается описанием экранов и алгоритмов обработки данных, ставит ОДНУ ЗАДАЧУ НА ОДНОГО ПРОГРАММИСТА (full-stack), который делает всё. Идеально начинать карьеру в таких проектах и из них расти дальше.

Но UI+БД+Логика - это прям жесткий монолит 😢 Есть другой вариант монолитной архитектуры, когда это касается только сервера.

Из-за наличия мобильных приложений, которым проблематично напрямую делать SQL-запросы в БД, UI начали активно выносить из этого жесткого монолита. И сейчас аналитики как правило делают задачи отдельно на UI (Frontend / Mobile), и отдельно на API+БД (Backend). При этом проект может всё еще оставться монолитным в части сервера, так как вся-вся логика обработки данных лежит в одном месте, а все данные в одной БД.

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

Почему монолиты приносят страдания для больших проектов? Расскажу в следующем посте 👇

#АрхитектураGA

✖️ Проблемы монолита с примерами по проекту ✖️

🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности: память, ядра процессора и другие.

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

> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям приложения. В архитектуре с сервисами добавить копии можно было бы только на основной сервис поиска врачей, который будут “атаковать” в процессе рекламы.


🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных системах. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.

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


🔺3. Сложность масштабирования команды
Приходя в проект, аналитики, разработчики и тестировщики должны узнать очень много обо всех частях системы, чтобы не вредить ей при развитии и знать, как очередная маленькая функция, может задеть 100 существующих.

Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.
В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.


🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.


🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.

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

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


Это основные проблемы монолитной архитектуры 😔

Но в ней есть и очень много плюсов:
+ легкость в разработке
+ не нужна супер-опытная команда
+ нет проблем в синхронизации данных, которые распределены по разным БД
+ легче устанавливать проект на сервере
Она идеальна для стартапов! 🚀

Монолит - это не плохо. Его можно сделать архитектурно красивым, и с ним будет интересно и приятно работать 🙌 Но всё зависит от опыта программистов, архитекторов и аналитиков, которые участвуют в разработке.

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

#АрхитектураGA #TelMedGA

🧱 Компоненты системы и их визуализация в схемах архитектуры 🧱

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

В качестве интерфейсов могут выступать UI (User Interface) или API (Application Programming Interface).

Компоненты системы можно поделить на несколько основных групп:

➕ Frontend / UI - приложения с пользовательским интерфейсом.
> iOS Telmed для пациента
> Android Telmed для пациента
> iOS TelmedDoc для для врача
> Admin Telmed - приложение администратора

➕ Backend / API - серверные приложения со своей логикой и API для взаимодействия с ними. Сюда относятся сервисы, микросервисы, API-Gateway и другие.
> Сервис интеграции с лабораториями по анализам с его REST API, по которому с ним будут взаимодействовать другие сервисы TelMed
> Сервис платежей с его REST API, по которому ним будут взаимодействовать другие сервисы TelMed

➕ БД - базы данных, такие как PostgreSQL.
> БД сервиса интеграции с лабораториями по анализам, PostgreSQL
> БД основная, PostgreSQL
> Локальная БД для iOS TelmedDoc, SQLite

➕Системы обмена сообщениями - очереди MQ / брокеры сообщений, такие как RabbitMQ, Kafka и другие.
> Очередь для обработки запросов на рассылку SMS-уведомлений, RabbitMQ


Компоненты выделяют в процессе проектирования архитектуры систем и отражают на схеме архитектуры.


Схема архитектуры может быть визуализирована в:

✔️Геометрические фигуры (прямоугольники, стрелки, облака, своим студентам даю спец. нотацию CR, которую можно использовать в их проектах).
✔️Нотация C4 - идеально, когда нужна чисто техническая архитектура.
✔️Archimate - очень связана с бизнес-контекстом.

Другие нотации моделирования можно посмотреть в этой статье.


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

#АрхитектураGA #TelMedGA

⭐️ Нотация моделирования C4 - гайд с примерами ⭐️

Нотация C4 - одна из самых удобных для визуализации архитектуры информационных систем. Разработана в 2011 году Саймоном Брауном, опытным архитектором.

Создание нотации было мотивировано необходимостью улучшить понимание и документирование архитектуры программных систем как для технических специалистов, так и для бизнес-стейкхолдеров. Это делает её значимым инструментом как для СА в работе с программистами, так и для БА в работе с представителями бизнеса.

За C4 стоят четыре уровня детализации.

⭐️ Context
Показывает самый верхний уровень - систему и её окружение.
На С4/Context отражены:
+ система,
+ пользователи,
+ интеграции.

⭐️ Container
Показывает компоненты системы. Каждый компонент на схеме - это отдельный контейнер. Обычно на проекте всего одна схема контейнеров, которая детализирует одну систему, представленную на уровне С4/Context.
На С4/Container отражены:
+ мобильные приложения, сайты, веб-приложения,
+ сервер-приложение, сервисы и микросервисы,
+ БД и хранилища,
+ очереди и брокеры.
*Осторожнее с определением слова “компонент” при работе с C4.

⭐️ Component
Детализирует каждый контейнер. Схемы C4/Component на практике делают только для части контейнеров:
+ Функциональные блоки или модули монолитного сервер-приложения, сложных сервисов и микросервисов.
+ Backend из сервисов и микросервисов, но в С4/Container его сделали как один контейнер - показывают сервисы и микросервисы.
+ Frontend (вебы, МП и др.) - детализируют редко, но в случаях наличия локальных БД, сложной логики, “толстых” клиентов, микрофронтендов, эта диаграмма очень выручает.

⭐️ Code
Самый бесполезный уровень, который быстро устаревает. Это признает даже сам создатель нотации и рекомендует её использовать только для брейншторма задач разрабтчиками, но не для хранения в документации и последующего сопровождения.


Смотрите прикрепленный к посту гайд, в нём больше наглядных примеров, инструменты для C4 и полезные ссылки! ❤️

#АрхитектураGA

🔸 Монолит, Сервисная и Микросервисная архитектура - сравнение 🔸

Для системных аналитиков важно не только знать, какие виды архитектур существуют, но и понимать их ключевые отличия и области применения. В этом посте мы познакомимся с наиболее распространенными видами архитектуры, чтобы затем показать их варианты реализации на примере проекта TelMed с использованием нотации C4.

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

БД:
Обычно используется одна БД, что упрощает взаимодействие между различными частями приложения, но может стать узким местом при масштабировании.

Внутренние интеграции:
Все компоненты взаимодействуют только на уровне кода, интеграции по API и другими способами не нужны.


🔸 Сервисная архитектура SOA (Service-Oriented Architecture)
SOA разделяет функциональность на отдельные сервисы, которые взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.

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

Например, в Интернет-магазине сервис каталога и сервис заказов можно поделить, чтобы инсталлировать на сервере 10 копий сервиса каталога, но всего 3 копии сервиса заказов, т.к. до заказа товаров доходит меньше пользователей чем тех, кто просто смотрит каталог.

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

Внутренние интеграции:
Сервисы интегрируются через API, что упрощает интеграцию. Могут использовать шину - ESB.

#АрхитектураGA #TelMedGA

Продолжение 👇

🔸 Микросервисная архитектура MSA (Microservice Architecture)
MSA состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет одну бизнес-функцию.

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

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

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

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



Выбор архитектуры проекта зависит от специфики и требований к системе. На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

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

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

#АрхитектураGA

Заряжающие выходные 🙌🌸🌱

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

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

А если вы уже хорошо отдохнули в первой половине каникул, чувствуете заряд энергии, и сейчас хочется сделать что-то полезное для карьерного роста, то предлагаю заглянуть в Материалы для самостоятельного обучения GetAnalyst, которые мы собрали для вас 🙌

Эти практические занятия помогут вам с легкостью и без препятствий начать идти по пути карьерного роста в продолжении 2024 года! 🎉🌱

💫 Архитектура в C4 / Context - проект TelMed 💫

Самый верхний уровень C4 / Context показывает систему и её окружение. Проектируя его, мы не заморачиваемся с тем, какой подход к архитектуре будет выбран — будь то монолит, сервисно-ориентированная архитектура или микросервисы.

Все, что показывает C4 / Context:
1. Пользователей, которые работают с системой.
2. Интеграции с внешними системами.

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

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

А интеграции это то, что нужно знать о любой системе. Это вся техническая суть C4 / Context.

Интеграции влияют на:
+ Работу отдельных бизнес-процессов в системе и синхронизацию данных по ним, а также на работу с данными в системе в целом.
+ Доступ бизнеса к данным по отдельным бизнес-процессам через внешние приложения, благодаря настроенной синхронизации.
+ Безопасность, так как каждая точка интеграции в системе это потенциальное место для атаки.
+ Масштабируемость, так как в системе одновременно может работать большое количество пользователей и важно понимать, как много одновременных запросов от нашей системы сможет обрабатывать внешняя система.

Пример схемы проекта по телемедицине TelMed поможет нам понять, как реализуется C4 / Context на практике. См. картинку к посту.

Подробный гайд по всем уровням нотации моделирования архитектуры C4 тут, если вы пропустили его на прошлой неделе и хорошо отдохнули на праздничных выходных 💫

Вопросы по схеме? Пишите комментарии.
Всё понятно и готовы идти дальше? Ставьте 👍

#АрхитектураGA #TelMedGA

🪨 Монолитная архитектура в C4 / Container - пример для проекта TelMed 🪨

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

Для демонстрации воспользуюсь C4 / Container (контейнеры) и покажу, как она расширяет предыдущий уровень C4 / Context.

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

Таже в нашем проекте мы избегаем жесткой монолитной архитектуры — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend. Такое решение обусловлено наличием мобильных приложений, для которых в любом случае потребуется разработка API.

Итого, мы создаем современную версию монолитной архитектуры, где монолитным остается только Backend (приложение для сервера).

Внутри монолитного Backend можно будет организовать функциональные модули. Их обычно показывают на схеме C4 / Component. Модульный монолит в будущем поможет легче переехать на сервисную архитектуру, если это потребуется.

Основное на схеме C4 / Container для монолита:
- Пользователи.
- Внешние системы и оборудование.
- Приложения пользователей.
- Монолитное сервер-приложение - Backend.
- Базы данных - для монолита одна, отдельные схемы не отражают.
- Очереди сообщений, брокеры.

Для монолитной системы онлайн-приёмов к врачам пример схемы есть ✅ Схема прикреплена к посту.


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

1. Делать точные и технически грамотные постановки задач на разработчиков, в частности, на интеграции систем.
2. Понимать нефункциональные требования, и зачем мы их делаем. В частности про безопасность, надежность и масштабирование.
3. Уверенно чувствовать себя в диалогах с разработчиками и архитекторами, потому что понимаешь всё и не теряешься, когда тебя просят задокументировать архитектуру.

Разбирайте и запоминайте, чтобы в будущем перенести этот опыт на свои задачи 🙌

#АрхитектураGA #TelMedGA

🖥 Сервисная архитектура - что важно знать системному аналитику 🖥

Сервис-ориентированная архитектура (SOA) представляет собой подход, который позволяет разрабатывать приложения как набор взаимосвязанных сервисов.

Когда мы думаем о серверной части приложения Backend, то надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может быть установлен на отдельном сервере, иметь свою собственную базу данных и обновляться независимо от остальных.

Эти сервисы общаются друг с другом, обычно через веб-сервисы или API, для выполнения различных бизнес-задач.

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


Ключевые особенности SOA + отличия от Монолита:

💪 Backend разбивается на отдельные, независимые сервисы.

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

💪 Сервисы могут масштабироваться независимо друг от друга как горизонтально, так и вертикально, что оптимизирует ресурсное использование и управление нагрузкой.

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

💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть сервис анализов может быть на PHP, а вся остальная система на Java. Это позволяет программистам пробовать осторожно внедрять новые технологии в проекты при разработке новых сервисов.

#АрхитектураGA #TelMedGA

🌱 Микросервисная архитектура (MSA) 🌱

Микросервисная архитектура (MSA - MicroService Architecture) - принцип разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.

Микросервисы обычно общаются с другими сервисами через HTTP API, REST API, также наблюдаются тренды внедрения gRPC.


Ключевые особенности MSA и отличия от SOA:

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

💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга. То же верно и для SOA.

💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи. То же, что и в SOA.

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

💪 По классическому шаблону MSA для каждого микросервиса делают свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.

💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).

Примеры мировых проектов с MSA:
🔸 Netflix: микросервисы для стриминга видео, рекомендаций контента, управления профилями пользователей и другие.
🔸 Amazon: сервисы управления заказами, обработки платежей, управления каталогом товаров и другие.
🔸 Банковская сфера: микросервисы аутентификации и авторизации, управления счетами, уведомлений и другие.

Ключевые отличия между SOA и MSA показала на прикрепленной к посту картинке. Раскроем каждый пункт по особенностям SOA в следующем посте сегодня 😉

#АрхитектураGA

🌱 Микросервисная архитектура (MSA) - детальный разбор с примерами 🌱

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


Разбираем ключевые особенности на примерах:

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

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

В TelMed можно выделить микросервисы управление записями на приём, управления записями о докторах, обработки платежей. В SOA сервисы управления записями на приём и докторами могли бы быть объединены в один сервис общей логики.

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


💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга.

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

Тестирование, программирование и релизы совершенно не пересекаются, и команды могут не бояться задеть друг-друга или внести несовместимые изменения в код. Это разные кодовые базы.

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


💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи.

В одном микросервисе могут использовать реляционную СУБД PostgreSQL, в то время как для другого подберут нереляционную СУБД MongoDB.

То же верно и для языков программирования.

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


Продолжение 👇

#АрхитектураGA #TelMedGA

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

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


💪 По классическому шаблону MSA для каждого микросервиса делают одну свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.

Это позволяет быть микросервисам полностью независимыми. В SOA при обновлении структуры БД могут стать недоступны все связанные с ней сервисы, которых может быть 5. А в MSA при обновлении одной БД может быть недоступен только один связанный с ней микросервис.


💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).


🔸 Два самых важных отличия между SOA и MSA - размеры сервисов и количество БД на один сервис. Остальное во многом схоже.


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

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

#АрхитектураGA #TelMedGA

Архитектура для аналитиков: опыт работы здесь 🙌

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

🌟 Проектирование архитектуры
🌟 Старт предобучения 28 мая 2024
🌟 Подробности о программе и запись

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

Один из важных отзывов, повторяемый разными словами в чатах:

“Есть возможность попрактиковаться в проектировании архитектурного решения, выйти за пределы "пузыря" моей работы и налаженных процессов на работе”

Эта программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, и хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.

🎁 С 15 до 22 мая открыта предзапись на специальных условиях + дополнительное обучение по REST API в подарок.

Для всех, кто оставлял запросы до сегодняшнего дня и уже связался с нами, действует аналогичное предложение 🎁

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

Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌

2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!