🙌 Новый эпизод подкаста GetAnalyst про Нефункциональные требования 🙌

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

Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.

1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.

📚 Статья к подкасту


Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify

Делитесь с коллегами и подписывайтесь на всех площадках! 😉

🔔 Завершаем предзапись на архитектуру сегодня в 23:59 Мск🔔

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

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

А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳

Решила пойти не думая, т.к. предыдущие курсы, которые прошла, очень понравились

подачей, объемом информации и, самое главное, качественной объемной практикой с ДЗ и качественной проверкой ДЗ.

Задания не абстрактные, а конкретные, жизненные, привязанные к системам, которыми мы пользуемся ежедневно. Выполняя задание, мы можем сразу увидеть как это все работает уже со стороны не только пользователя, но и аналитика.

Было очень интересно познавать, как это работает с точки зрения архитектуры, микросервисов и БД. Хочу отметить, что проверка ДЗ ведется глубоко и индивидуально, "не для галочки".

Больше обратной связи будем постепенно добавлять на сайт 💛

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

Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!

Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!

✅ Шаблон Draw.Io для C4 - примеры для проекта TelMed ✅

Собрала Draw.Io с примером для проекта TelMed и структурировала информацию для вас.

1. Страница "Элементы C4"
На ней вы найдете сгруппированные элементы, которые могут присутствовать на каждом из уровней C4, которые реально используются в проектах (Context, Container, Component).
Также мини-инструкция, как включить эти элементы в Draw.Io в левой панели.

2. Страница "С4 - Проект TelMed от GetAnalyst"
На ней вы найдете:
+ Проект TelMed - C4 / Context (пояснения тут)
+ Проект TelMed - C4 / Container для монолитной архитектуры (пояснения тут)
+ Проект TelMed - C4 / Container для смешанной архитектуры - сервисная + микросервисная (пояснения тут)


📌 Файл Draw.Io для просмотра в онлайн:
https://app.diagrams.net/#G1nk3D0XqRQ9A-2Bw9yGlLY2ZOOutSEStR#%7B%22pageId%22%3A%22qvlD7eRmiriUJArze8cl%22%7D
Для просмотра потребуется авторизация на Google Диске.


Как забрать себе и использовать:
📌 Файл Draw.Io, который вы можете сохранить себе, доступен по этой ссылке
1. Перейти по ссылке.
2. Сверху будет иконка "Скачать"
3. После скачивания:
3.1. Загружаете на свой гугл-диск и открываете с помощью приложения draw io.
3.2. Открываете на десктопном (установленном на компьютер) draw io.


Теперь вы можете самостоятельно создавать C4 и подглядывать на пример, который сделан согласно нотации на 100%.

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

💫 Как быстро разобраться с новым API: REST, SOAP, GraphQL, и другие 💫

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

Мои первые API, с которыми я начинала работать, были REST и SOAP. Сначала я знакомилась с ними в интеграциях, потом при проектировании методов и постановке задач на Backend-разработчиков.

Больше всего опыта у меня связано с REST и он основа моих знаний. одновременно с ним был SOAP, но в меньших объемах. Когда появилась потребность узнать WebSocket, я уже интуитивно понимала, что важно искать в API-документации и куда смотреть, чтобы разобраться.

Выработался алгоритм “как в знакомиться с новым способом обмена данными между системами”. Так что GraphQL, SDK и прочие страшные на первый взгляд названия уже не были страшны.

Как я вижу - изучение API сравнимо с изучением иностранных языков. С детства ты учишь и используешь один язык (для меня это был REST API), в школе тебя заставляют учить второй язык и он дается тяжело. Из любопытства учишь 3-ий, и начинаешь понимать особенности “как учить”. А с 4-ого тебе всё легко 🙃

Делюсь своим подходом к изучению API с вами 💫

-------------
С чего начать изучение нового API?

1️⃣ Узнать общую информацию
2️⃣ Принцип формирования URL запроса
3️⃣ Принцип формирования Body запроса
4️⃣ Принцип формирования ответа (коды + тело)
5️⃣ Требования к авторизации и аутентификации запросов
6️⃣ Примеры документации
7️⃣ Тестирование через Postman или другие инструменты
🎱 Всё остальное познается через практику и опыт работы над проектами.
-------------

Подробнее каждый пункт разберу в следующем посте 👇

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

💫 Пошаговый план: с чего начать изучение нового API? 💫

1️⃣ Узнать общую информацию
Найдите статьи в сети, где рассказывают об использовании:
+ назначение,
+ общие принципы,
+ особенности и отличия от других API,
+ примеры использования в разных системах,
+ для каких видов архитектуры подходит,
+ влияние на выполнение нефункциональных требований проекта (НФТ).

2️⃣ Принцип формирования URL запроса
Есть ли типы методов, по аналогии с REST: POST, GET, PUT и другие.
Принцип формирования адреса запроса: структура и нейминг (именование).

3️⃣ Принцип формирования Body запроса
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.

4️⃣ Принцип формирования ответа (коды + тело)
+ Используемые стандартизованные коды ошибок (по аналогии со стандартными кодами HTTP-200, HTTP-404 и др).
+ Возможность и рекомендации для использования внутренних кодов ошибок.
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.


5️⃣ Требования к авторизации и аутентификации запросов
+ Какие способы авторизации используются.
+ Как она настраивается для запросов.
+ Как авторизационные данные хранятся на сервере для всей системы или для отдельных пользователей.

6️⃣ Примеры документации
+ Ищу примеры API-документации, которую можно протестировать.
+ Примеры документации, которая легко и понятно читается, чтобы использовать за образец на будущее при постановке задач на бэкенд разработчиков.
+ Также примеры документации, оформленной через разные инструменты (например, Swagger).

7️⃣ Тестирование через Postman или другие инструменты
+ Сначала определяю список инструментов, через которые можно проверять методы API (Postman, Swagger, Insomnia и другие).
+ Потом список инструментов, через которые можно документировать методы API (Confluence не считается).
+ Затем тестирую API и создаю коллекции запросов, создаю примеры документации, которые потенциально отправляются в моё портфолио.

🎱 Всё остальное познается через практику и опыт работы над проектами.

Этот подход точно применим для REST, SOAP, WebSocket, gRPC, GraphQL.

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

Делитесь с коллегами и сохраняйте в закладки ❤️

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

🕘 Планирование: как успеть всё и ничего не забыть? 🕘

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

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

Я серьёзно занялась этим вопросом, когда начала замечать как жадно беру на себя всё больше и больше задач, но ничего не успеваю. Jira и регулярные отчеты перед командами и заказчиками иногда заставляли краснеть. А чтобы это было реально “иногда”,
мне приходилось работать больше и без входных, и никто за это не платил и ничего не обещал. Это была моя инициатива и я о ней никому не говорила.

Я же обещала, значит сделаю. Пусть и ценой сна, личной жизни и отдыха.

Лучший способ сгореть на работе. Почти так и получалось.

Чтение в моей жизни всегда было регулярным занятием. До определенного момента это была только классическая литература, детективы и романы, ИТ-книги. Но пост в Instagram и приближающееся выгорание принесли в мою жизнь судьбоносную книгу “То, как мы работаем - не работает”. После её прочтения я полностью переключилась на профессиональную литературу: управление временем, менеджмент и так далее. Кстати, сейчас перечитываю эту книгу, чтобы напомнить себе важные правила.

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

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

Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.

👇👇👇

🕘 Планирование: как успеть всё и ничего не забыть? 🕘

Начинала с принципа “Я успею всё за сегодня”. Пришла к “1 день = 1 главная задача”. Но поверьте - меня частенько шатает.

В ежедневнике за 2023-2024 так:
1. 10+ задач на день
2. 5-10 задач на день
3. 3-5 задач на день
4. 1-2 задачи на день + мелочи типа “разгребать чаты”
5. 3-5 задач на день
6. 5-10 задач….
А дальше вы догадались 🙂

Ревью делаю каждые 3-6 месяцев. Психую, что опять скатилась в многозадачность, и иду обратно к фокусировке внимания на “1 задача на 1 день”. При адекватном планировании жизнь гораздо счастливее.

Важное, чем хочу поделиться:
1. Я успеваю не всё, что у меня в планах на день. Поэтому пт всегда отдаю на “хвосты”.
2. Все задачи в памяти ежедневника. Голова - чтобы думать, а не чтобы хранить в ней тонны ненужной и нервирующей информации.
3. Учеба - тоже задача. Пусть и дополнительная к работе. На следующий день после учебы нужен отдых после работы.
4. Всю мелочевку на вечер - разборы чатов и почты раз в день, не более 1 часа, либо два раза по 30 минут. Это самое сложное с учетом специфики работы аналитиков.
5. Все рутинные и отчетные созвоны на вечер, когда голова уже работает не так бодро.
6. На каждые 90 минут в расписании 5-10 мин прогулки. В плане есть обед и перекусы.
7. Время для спортзала и другие личные планы тоже в ежедневнике.

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

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

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

🐙 Пошаговый план в действии: знакомство с GraphQL 🐙

Сегодня мы погрузимся в GraphQL и разберем, как использовать “Пошаговый план: с чего начать изучение нового API?”.

Рассмотрим основные пункты и приведу примеры для проекта #TelMedGA 💊💉🧑‍⚕


1️⃣ Узнать общую информацию

➕ Назначение:
Запрашивать только те данные от сервера, которые нужны клиенту.

GraphQL — это язык запросов для API, который позволяет клиентам запрашивать только те данные, которые им нужны.

Интересно обратить внимание на терминологию:

- Язык запросов (GraphQL) фокусируется на том, как клиент формирует запросы к данным и какие операции он может выполнять. Это инструмент для взаимодействия с данными.
- Архитектурный стиль (REST) описывает, как строится и организуется сама система API, включая правила и стандарты для взаимодействия между клиентами и серверами.


➕ Общие принципы
1. Запросы к серверу используются для получения данных, а мутации — для их изменения.
2. Все запросы и мутации к одному URL.
3. Сервер GraphQL определяет схему, которая описывает типы данных и операции, доступные для клиентов.
4. Клиенты могут запрашивать только те данные, которые им нужны. Это уменьшает объем передаваемых данных и улучшает производительность.


➕ Особенности и отличия от других API
1. В отличие от REST, где нужно делать отдельный URL для каждого запроса (метода / функции), в GraphQL нужен только один URL для всех запросов.
2. За один запрос можно выбрать только те данные о сущностях, которые нужны. Сравнимо с SQL (тоже язык запросов), только это про API.
3. Язык запросов свой и не похож на другие API, а вот ответ обычно возвращается в формате JSON. Структура JSON строится на основе запроса.

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

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

🐙 Пошаговый план в действии: ссылки по GraphQL 🐙

➕ Примеры использования:

1. Социальные сети (Facebook)
Непубличный внутренний API для мобильных и других приложений. Не путать с Graph API, это другое.
https://stackoverflow.com/questions/42750054/is-facebooks-graph-api-using-graphql
Позволяет мобильным приложениям минимизировать объем передаваемых данных, что важно для производительности и потребления трафика.

2. Финансовые приложения (Stripe)
https://docs.stripe.com/connectors/adobe-commerce/custom-storefront
Оптимизирует запросы для повышения производительности и уменьшения задержек за счет получения только нужных данных от сервера.

3. Confluence
https://developer.atlassian.com/platform/atlassian-graphql-api/graphql/#overview
Возможность запрашивать только нужные данные из различных сущностей Confluence в одном запросе, что упрощает интеграцию и повышает производительность.


➕ Для каких видов архитектуры подходит:
Можно использовать в любой архитектуре. Важно понимать, что он создан для снижения объема передаваемых данных по сети.

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


➕ Влияние на выполнение НФТ:
1. Производительность: Оптимизация запросов за счет получения только необходимых данных.
2. Масштабируемость: Следствие производительности, позволяет лучше использовать ресурсы памяти и не покупать лишние.


➕ Полезные ресурсы для изучения:

1. Введение в GraphQL от GraphQL Foundation (ENG) - первоисточник + переводчик всегда лучше любого другого ресурса.
2. Серия постов по GraphQL от GetAnalyst со всеми примерами, потому что разбор почти по всему остальному плану знакомства я уже делала для вас на примере другого проекта.
3. В чем разница между GraphQL и REST от Amazon - среднего уровня статья, больше про теорию.
4. Руководство по GraphQL - потрясающая подборка примеров, мой любимый подход “теория на практике”.

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

💥Онлайн-практика по Архитектуре для системных аналитиков УЖЕ ЗАВТРА 💥

Архитектура и API: от монолита к микросервисам
🗓 29 МАЯ, 19:00 МСК (СРЕДА)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

План:
1. Роль системного аналитика в проектировании архитектуры.
2. Важная теория: архитектура и API.
3. Проектирование монолита.
4. Переход к сервисам (SOA) и микросервисам (MSA).
5. Выбор API для проекта и его обоснование.

За один вечер:
🌟 Поймёте основы проектирования архитектуры.
🌟 Разберётесь в отличиях монолита, сервисов и микросервисов.
🌟 Познакомитесь с востребованными API.
🌟 Получите готовые схемы и подходы по проектированию.

Регистрируйтесь, чтобы не пропустить! 😉

🐙 Пошаговый план по API в действии: примеры GraphQL 🐙

Продолжаем вчерашнюю серию постов про GraphQL 🙌


2️⃣ Принцип формирования URL запроса

HTTP - основной протокол через который работает GraphQL.

Все запросы отправляются на один и тот же URL (эндпоинт), обычно /graphql. Это главное отличие от REST.

HTTP-сервер GraphQL должен уметь обрабатывать HTTP-методы GET и POST.

Если используется метод GET, то URL-запроса будет выглядеть так:

https://telmed.com/graphql?query={appointments(doctorId:12345){date,time,doctor{name,specialization}}}

- это запрос на получение всех записей на прием для конкретного врача. Вся структура запроса отправляется в query-параметры URL.

Если используется метод POST, то URL-запроса будет:

https://telmed.com/graphql

А в теле запроса будут все необходимые параметры.

Предпочтение для всех запросов отдаётся методу POST, чтобы не засорять URL-запроса, т.к. его длина обычно ограничена.

🔗 Источник



3️⃣ Принцип формирования Body запроса

3 ключевых принципа формирования Body запроса в GraphQL:

1. Запросы (Queries)
2. Мутации (Mutations)
3. Подписки (Subscriptions)

🌸 Запросы (Queries)
Запросы используются для получения данных. Клиент определяет, какие именно данные ему нужны, и получает их в виде JSON-объекта. В запросах можно использовать фильтры для более точного выбора данных.
Похоже на GET в REST API.

Пример - Просмотр списка записей на прием к врачу с фильтром по доктору

POST https://telmed.com/graphql

query {
appointments(doctorId: "doctor-456") {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}

🌸 Мутации (Mutations)

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

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

🐙 Пошаговый план в действии: примеры GraphQL 🐙

3️⃣ Принцип формирования Body запроса

🌸 Мутации (Mutations)

Мутации используются для изменения данных на сервере, например, создания, обновления или удаления записей. Мутации похожи на запросы, но кроме получения данных, они изменяют их на сервере.
Похоже на POST, PUT, PATCH и DELETE в REST API.

Пример мутации - Запись на прием к врачу

POST https://telmed.com/graphql

mutation {
createAppointment(input: {
date: "2024-06-01",
time: "10:00",
patientId: "patient-123",
doctorId: "doctor-456"
}) {
appointment {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}
}

Пример мутации - Изменение записи на прием к врачу

POST https://telmed.com/graphql

mutation {
updateAppointment(id: "appointment-789", input: {
date: "2024-06-02",
time: "14:00"
}) {
appointment {
id
date
time
patient {
id
name
}
doctor {
id
name
}
}
}
}

❗️Обращаем внимание на название методов в мутациях - именно в них ответственность за создание и изменение данных: createAppointment и updateAppointment.


🌸 Подписки (Subscriptions)
Подписки позволяют клиенту получать данные в реальном времени при изменении состояния данных на сервере. Они полезны для таких сценариев, как обновления в реальном времени.
Похоже на WebSocket.

Далее я рекомендую посмотреть Серию постов по GraphQL от GetAnalyst с дополнительными примерами.

Кажется, что по GraphQL напрашивается отдельное пособие в блог в ближайшее время, чтобы сразу с тестированием через Postman, набором примеров и ссылок?

Давайте больше 111 ❤️, чтобы я поняла насколько актуально))

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

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Архитектура и API: от монолита к микросервисам
⏰ 19:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Я каждый раз пересматриваю обратную связь после вебинаров, и в этот раз на “Архитектуру и API” она особенная! Еще больше развернутых сообщений, чем обычно.

Искренне благодарю за то, что создаете эту атмосферу живого общения и большой аудитории в онлайн, задаете вопросы и учитесь ❤️ Вы делаете вебинары такими!


Екатерина:

Было невероятно интересно и будучи Мидл были новые знания и очень интересная информация! Спасибо

Анна:

Екатерина просто ОГОНЬ, лучше спикера еще не слышала

Константин:

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

Евгения:

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

Итоги:

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

✅ Разобрали применение SOAP, gRPC, REST, GraphQL и WebSocket в различных видах архитектуры. Узнали рекомендации по выбору API.

✅ Спроектировали схему монолитной архитектуры для реального проекта по системе страхования. Определили все интеграции и приложения.

✅ Затем сделали схему архитектуры модульного монолита.

✅ Разобрали принципы проектирования сервисной (SOA) и микросервисной (MSA) архитектуры. Определили отличия между ними на примерах. Сделали схему смешанной архитектуры SOA + MSA для проекта: переезд от монолита к микросервисам.


Было много ценной информации, которую сразу применяли на практике. Уложились в 3 часа)))

По итогам получили три схемы архитектуры и практический кейс в копилку! 🙌

❗️Про запись информация будет опубликована до завтра


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

Жду встречи с новой командой! ❤️


Желаю вам хороших новостей и яркого дня сегодня!

🏰 Системный аналитик в задачах на архитектуру 🏰

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

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

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

Ниже приведен краткий гайд по основным задачам СА связанным с проектированием архитектуры:

🟢 1. Исследование и анализ

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

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


🟢 2. Выбор основного подхода к проектированию архитектуры

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


+ Оценка различных архитектурных стилей (монолитная, микросервисная, сервисно-ориентированная и т.д.).
+ Выбор подходящего архитектурного стиля на основе требований и ограничений. Если небольшой и новый проект, то тут чаще всего останавливаются на монолите.

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

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

🏰 Как Системный аналитик в задачах на архитектуру? 🏰

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

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

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


🟢 3. Формирование концептуальной схемы

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

+ Создание концептуальной схемы архитектуры, охватывающей основные компоненты и их взаимодействия.
+ Определение границ и ответственности по функциональности для каждого компонента.
+ Распределение данных по различным БД и подбор СУБД.
+ Моделирование взаимодействий между компонентами с учетом функциональных и нефункциональных требований - выбор API, определение мест, где нужны Kafka, RabbtMQ или другие решения.
+ Проведение обзорных сессий с заинтересованными сторонами для получения обратной связи и внесения корректировок.


🟢 4. Влияние нефункциональных требований

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

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

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


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

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

🐙 Знакомство с gRPC 🐙

1️⃣ Общая информация

▫️gRPC — система удалённого вызова процедур.
Разработана в Google в 2015 году.

▫️Использует Protocol Buffers — protobuf — буферный протокол сериализации данных, проще говоря преобразования данных.

▫️RPC (Remote Procedure Call) — это способ, который позволяет одной программе на сервере А вызвать функцию в другой программе, которая находится на другом сервере B, как будто это локальный вызов. Другими словами, как будто вызов функции происходит на одном сервере A, а не на разных.

▫️Зачем нужна сериализация в gRPC?
(= Зачем нужно преобразование данных?)
1. Сериализация позволяет компактно представлять данные в бинарном виде, что уменьшает объем передаваемой информации и ускоряет передачу.
2. Сериализованные данные можно передавать между разными системами и языками программирования, сохраняя их структуру и типы данных.
3. Сериализованные данные проще проверять на целостность и корректность при передаче по сети.


➕ Назначение gRPC
Оптимизировать связь между приложениями и сервисами с помощью высокопроизводительных RPC.


➕ Общие принципы

1. gRPC использует протокол HTTP/2 для транспортировки данных, обеспечивая высокую производительность и двунаправленное потоковое взаимодействие.

2. Определение контрактов между клиентом и сервером осуществляется с помощью proto-файлов.

3. Proto-файлы компактны и позволяют автоматически генерировать исходный код для различных языков программирования.

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


➕ Особенности и отличия от других API

1. В отличие от REST, где каждый запрос требует нового HTTP-соединения, gRPC использует постоянное HTTP/2 соединение, что улучшает производительность.

2. Благодаря protobuf можно быстрее передавать данные по сети.


Итого:
gRPC выбираем, когда нужна высокая скорость обмена данными между системами или сервисами.

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

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

🐙 Примеры и ссылки по gRPC 🐙

➕ Примеры использования

▫️Google Cloud
Google активно использует gRPC в своих облачных сервисах.
https://cloud.google.com/api-gateway/docs/grpc-overview

▫️Netflix
Netflix применяет gRPC для внутренней связи между микросервисами.
gRPC обеспечивает высокую производительность и надежность передачи данных между различными микросервисами, что важно для масштабируемых систем потокового видео​.
https://www.cncf.io/blog/2021/08/04/grpc-in-action-example-using-java-microservices/

▫️Lyft (аналог Яндекс.Такси и Uber)
Использует gRPC для передачи данных о местоположении автомобилей в режиме реального времени.
Постоянное соединение gRPC позволяет непрерывно отправлять сообщения о местоположении автомобиля на мобильное приложение, что значительно улучшает пользовательский опыт и снижает задержки по сравнению с традиционным опросом сервера​.
https://www.redhat.com/architect/grpc-use-cases


➕ Для каких видов архитектуры подходит

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

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


➕ Влияние на выполнение НФТ

Высокая производительность (скорость обмена данными) за счет использования HTTP/2 и protobuf.


➕ Полезные ресурсы для изучения

1. Официальная документация gRPC

2. Подкаст GetAnalyst с Марией Кубениной по gRPC

3. Книга "gRPC: запуск и эксплуатация облачных приложений. Go и Java для Docker и Kubernetes", Индрасири Касун, Курупу Данеш:
Отличное руководство для разработчиков, но немного перебор для аналитиков. Полезно пролистать понятные страницы.

4. Примеры работы с gRPC API от Яндекс.Cloud тут 🙂


Вот так я применяю Пошаговый план: с чего начать изучение нового API? - идеальная инструкция для знакомства с разными API. С ним последовательно можно найти самую важную информацию.

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