Системный Аналитик

Может, познакомимся?

🔹 Канал активно ведётся уже почти 2 года, появилось 17+ тысяч подписчиков, а мы до сих пор не знакомы друг с другом. Надо исправляться.

Есть идея создать на базе нашего канала группу-комьюнити системных аналитиков, чтобы:
1. Обмениваться опытом друг с другом
2. Узнавать, как там работается в других местах
3. Что там по ЗП
4. Ну и просто болтать

Естественно, модерация и все дела.

💡 Есть также идея проводить митапы пару раз в месяц на определённые темы, за которые будут голосовать люди. Но нужны энтузиасты, которые готовы выступать НА ПУБЛИКУ 😱

💬 Пишите в комментариях всё, что думаете по этому поводу.

Ну а ниже предлагаем ответить на несколько вопросов и чуть-чуть узнать друг о друге.

🙂 Шаблонизаторы

Шаблонизаторы — инструменты для автоматической генерации текстовых данных на основе шаблонов и входных данных.

Используются в:
▫️API-интеграции: генерация HTTP-запросов и ответов, JSON/XML-запросов (например, Mustache в OpenAPI/Swagger)
▫️ESB: преобразование входящих сообщений в нужный формат (Freemarker в Apache Camel)
▫️MQ: формирование сообщений перед отправкой в очередь (Jinja2 в Celery, Handlebars)
▫️ETL: шаблоны для преобразования данных при загрузке в хранилище
▫️Создание конфигурационных файлов для разных окружений (Helm)
▫️Генерация технической документации
▫️Коде: создание CRUD-операций, DTO (Data Transfer Object), API-клиентов
▫️SQL: генерация динамических SQL-запросов, шаблоны для отчётов и аналитики (например, Jinja2 в dbt, Mustache в SQLAlchemy)


Примеры

⏪ Динамическое создание сценариев для разных ролей пользователей ⏩

Шаблон описывает процесс оформления заказа, но меняются условия для разных ролей:
🟡администратор может менять статус вручную
🟡менеджер получает уведомление
🟡клиент видит статус в личном кабинете
Вместо 3-х сценариев используется шаблон с переменными {role}, {action}, {notification}.
Например, с помощью Jinja2, Mustache

⏪ Гибкое преобразование данных ⏩

Форматы сообщений генерируются из шаблонов (например, FreeMarker или Jinja2):
🟡для банка нужен XML-формат: шаблон payment_template.xml
🟡для маркетинговой платформы JSON: шаблон email_template.json
🟡для ERP CSV-файл: шаблон orders_template.csv
Если банк меняет XML-структуру, достаточно обновить шаблон, а не переделывать всю интеграцию


Примеры шаблонизаторов

📌 Mustache — универсальный шаблонизатор для API, UI, конфигураций, доступен для различных языков программирования, включая JavaScript, Python и Ruby

✏️ Как применить
Разработка микросервисного API для обработки заказов

Проблемы:
❌ API-документация устаревает, обновлятся вручную
❌ доп время на написание Swagger/OpenAPI-описаний
❌ разные версии API дублируют документацию

Пример решения:
✔️ создается шаблон, где параметры API (методы, URL, заголовки) подставляются динамически
✔️ Swagger/OpenAPI автоматически заполняется актуальными значениями
✔️ любое изменение в коде API сразу отражается в документации


📌 FreeMarker — шаблонизатор на Java
Используется для генерации текстовых выходных данных (HTML, конфигурационные файлы, исходный код)

✏️Как применить:
Разработка веб-приложения

1. Динамическая генерация страниц (баланс, последние транзакции) с неизменной версткой

Контроллер Spring Boot передаёт в шаблон FreeMarker объект пользователя с балансом и историей операций.
FreeMarker подставляет данные в HTML и формирует готовую страницу
🔸если баланс больше 100 000₽, показывается статус «Премиум-клиент»
🔸если меньше 1000₽, предлагается «Пополнить баланс»
🔸история платежей подставляется в виде таблицы с циклом

2. Персонализация контента: разные предложения для пользователей

В шаблоне используются условия <#if> — если клиент VIP, добавляется блок с индивидуальными предложениями.
Контент обновляется без изменения логики бэкенда
🔸обычный клиент: «Оформите кредит под 10%»
🔸VIP-клиент: «Специальное предложение: кредит под 5%»

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

Общие шаблоны (layouts) с подключением через include
Если нужно изменить меню — правится один файл
-- все страницы используют один header.ftl* с логотипом и навигацией
-- в footer.ftl хранится контактная информация
-- основной шаблон (base.ftl) объединяет их в одну структуру
*FreeMarker Template Language (FTL)


📎 Материалы

1. Что такое и зачем нужны шаблонизаторы HTML
2. Текстовые шаблонизаторы и их реализация
3. Три неочевидных примера использования шаблонизаторов в backend-е
4. Шаблонизаторы HTML: что это и стоит ли их использовать в разработке
5. 15 шаблонизаторов для фронтенд-разработки
6. 6 лучших шаблонизаторов на PHP
7. 5 популярных PHP-шаблонизаторов
8. ТОП-10 шаблонизаторов HTML для web-разработки

#инфраструктура

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

💳 Архитектура платежных систем

Термины

🔹платежная система — инфраструктура для маршрутизации платежей, безопасности операций и расчетов между банками (Мир, Visa, MasterCard)

🔹эквайер — банк/финансовая организация, обслуживает терминалы и принимает платежи от клиентов

🔹процессинговый центр (ПЦ) — система для обработки платежных запросов, передает их в платежную систему и банк-эмитент

🔹банк-эмитент — банк,который выпустил карту клиента; он проверяет баланс, авторизует платеж и списывает средства


Рассмотрим обобщенно: как происходит платеж с момента поднесения карты к терминалу эквайринга до списания средств со счета

1️⃣ Поднесение карты к терминалу эквайринга

Карту подносят к терминалу. Начинается процесс авторизации платежа
Терминал может быть:
🔵физическим (например, POS-терминал в магазине)
🔵виртуальным (веб-форма на сайте, мобильное приложение)

Платежная система (например, «Мир») определяет стандарты передачи данных (например, MIR Accept) и их безопасность

2️⃣ Передача данных с терминала эквайринга

Карта успешно считана, терминал передает платежные данные (номер карты, срок действия, CVV, сумму транзакции) в ПЦ эквайера через защищенное соединение

3️⃣ Передача данных в ПЦ и платежную систему

ПЦ эквайера принимает платежный запрос, проверяет его корректность и передает в платежную систему (например, «Мир»)

Платежная система маршрутизирует платеж:
🔵определет банк-эмитент по номеру карты (BIN)
🔵отправляет ему запрос на авторизацию

4️⃣ Проверка данных и авторизация в банке-эмитенте

Банк-эмитент проверяет:
🔵достаточно ли средств на счете
🔵корректно введенны данные
🔵антифрод-проверки
🔵есть ли блокировки на карте и т.д.

Если все ок, банк-эмитент выдает авторизацию и передает ответ (одобрение/отказ в проведении транзакции) платежной системе

Платежная система передает его в ПЦ эквайера - > эквайрер передает результат на терминал

5️⃣ Завершение транзакции и списание средств

После авторизации банк-эмитент резервирует сумму на счете покупателя

ПЦ передает подтверждение эквайеру
Эквайер передает его продавцу -> продавец получает платеж, транзакция завершается

Платежная система участвует в клиринге* и окончательных расчетах между банком-эквайером и банком-эмитентом

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


Примеры технологий на каждом этапе

1. Поднесение карты к терминалу эквайринга

⚪️NFC (Near Field Communication) — для передачи данных между картой и терминалом (в том числе для Apple Pay, Google Pay). Работает на основе RFID и требует наличия чипа в карте
⚪️RFID (Radio Frequency Identification) — передача данных между картой (тегом) и терминалом через радиоволны
⚪️EMV (Europay, MasterCard, Visa) — стандарт для карт с чипом с криптографическими алгоритмами защиты данных.
⚪️MIR Accept — аналогичный стандарт для платежной системы «Мир», дополненный механизмами защиты + адаптация к требованиям

2. Передача данных с терминала эквайринга

⚪️TLS (Transport Layer Security) — защищенный протокол передачи данных
⚪️API (REST, SOAP) — для интеграции с процессингом и банками-эквайерами

3. Передача данных в ПЦ и платежную систему

⚪️API
⚪️Очереди сообщений (Kafka, RabbitMQ) — для асинхронной обработки платежных запросов

4. Проверка данных и авторизация в банке-эмитенте

⚪️API
⚪️OAuth 2.0 — механизм аутентификации и авторизации между сервисами
⚪️Системы антифрода (например, машинное обучение)

5. Завершение транзакции и списание средств

⚪️Real-time Payment Systems (например, СБП) — системы моментального перевода средств.
⚪️API


📎 Материалы
1. Платежные системы простыми словами. Как устроены и зачем нужны Mastercard, Visa, МИР и прочие
2. Интернет-эквайринг «для чайников»
3. Интернет-эквайринг в картинках
4. Как работает интернет-эквайринг
5. Платёжный сервис в банке, часть первая
6. Как мы переезжали на новый платежный сервис
7. Путешествие финансовой транзакции
8. Платёжные системы

#интеграции

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✳️ Прокси-сервер

Прокси-сервер – промежуточный сервер между клиентом (пользователем / приложением) и сервером
🔵содержит прокси IP-адреса (индивидуальные IP-адреса для сокрытия реального IP)
🔵принимает запросы от клиента, обрабатывает и передает дальше
🔵может изменять или фильтровать данные

Отличие от балансировщика и VPN

🟠балансировщик нагрузки распределяет входящий трафик между серверами
🟡прокси - "посредник", без распределения нагрузки
🟠VPN (Virtual Private Network) создаёт защищённое соединение между клиентом и сервером, для шифрования и анонимности
🟡прокси может менять IP-адрес и фильтровать трафик, но не всегда шифрует данные


Для чего нужен?

Анонимность и скрытие IP-адреса
🔵пример: для доступа к заблокированному контенту с помощью зарубежного прокси

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

Контроль и фильтрация трафика
🔵блокирует доступ сотрудников к определенным сайтам

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


Пример работы

1️⃣ клиент отправляет запрос на доступ к ресурсу через прокси-сервер
2️⃣прокси принимает запрос и анализирует его (проверка политики доступа, фильтрация, логирование)
3️⃣©️ если данные есть в кэше, то прокси возвращает их без обращения к внешнему серверу
©️ если нет, то прокси пересылает запрос на целевой сервер
4️⃣сервер обрабатывает запрос и отправляет ответ прокси
5️⃣прокси передает ответ клиенту + может модифицировать его (сжать контент, удалить конфиденциальные данные)


Прямой и обратный прокси

Прямой
Клиент ➡ Прокси-сервер ➡ Интернет-ресурс ➡ Сервер
🟡перенаправляет запросы клиента в интернет, изменяет IP-адрес и фильтрует трафик
©️клиент знает о наличии прокси, и конфигурирует его

Обратный (реверсивный)
Клиент ➡ Интернет-ресурс ➡ Прокси-сервер ➡ Сервер
🟡работает на серверной стороне
🟡принимает запросы, но не передает их напрямую серверу, а перенаправляет на один / несколько серверов
©️ клиент не знает о нем


Примеры интеграции

Интеграция с CDN
▫️работает в связке с сетью доставки контента (CDN), кэширует и оптимизирует раздачу статических ресурсов

Интеграция с WAF (Web Application Firewall)
▫️фильтрует трафик через WAF для защиты веб-приложения от атак на уровне приложения

В микросервисной архитектуре
▫️управляет взаимодействием микросервисов (маршрутизация и балансировка трафика)
пример: сервис-меш с прокси для маршрутизации API-запросов между микросервисами


Пример архитектуры с прокси
[ Клиенты ] → [ Reverse Proxy ] → [ Балансировщик ] → [ Серверы приложений ] → [ БД ]

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


📎 Материалы

1. Прокси
2. Что такое прокси-сервер и как его настроить
3. Прокси-сервер: что это такое и нужен ли он вам?
4. Что такое прокси? Для самых маленьких
5. Что такое прямой прокси и обратный прокси
6. Разница между обратным и прямым прокси
7. Разница между прямым прокси, обратным прокси и балансировщиком нагрузки
8. Типы Прокси HTTP, HTTPS, Socks
9. VPN или прокси-сервер: что лучше и в чем разница?

📚Книги
Безопасность веб-приложений. Разведка, защита, нападение. — Хоффман Эндрю

#проектирование #инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

✍️ Балансировка нагрузки | продолжение

Ранее писали про балансировку нагрузки
Напомним, балансировка — механизм распределения входящих запросов между серверами

Уровни балансировки в модели OSI

💙сетевой уровень (L3, IP) – балансировка на основе IP-адресов
💙транспортный уровень (L4, TCP/UDP) – маршрутизация запросов по номерам портов и соединениям, без анализа содержимого пакетов
💙прикладной уровень (L7, HTTP/HTTPS) – анализ HTTP-запросов и маршрутизация на основе URL, заголовков или cookies


Типы балансировщиков

Аппаратные (Hardware Load Balancer, HLB)

- физические устройства с сетевыми процессорами (ASIC), которые обрабатывают пакеты быстрее, чем программные решения
- часто используются в крупных дата-центрах
⏩ примеры: F5 Big-IP, Citrix NetScaler

Как работают
➡️клиент отправляет запрос на IP-адрес балансировщика
➡️балансировщик обрабатывает запрос на аппаратном уровне
➡️трафик направляется на нужный сервер с мин задержками


Программные (Software Load Balancer, SLB)

- ПО на сервере, которое выполняет функции балансировки
- гибкое, дешевле аппаратных решений, но требует мощностей сервера
⏩ Nginx, HAProxy, Envoy

Как работают
➡️SLB развернут на виртуальной машине / физическом сервере
➡️принимает запросы и перенаправляет их на сервера по заданным алгоритмам
➡️может использовать L4 или L7-балансировку


Виртуальные (Virtual Load Balancer, VLB)
- программные балансировщики, работают в виртуальных средах или в облаке
- поддерживают авто-масштабирование (динамическое изменение кол-ва серверов)
⏩AWS ELB, Yandex Network Load Balancer

Как работают
➡️облачный балансировщик получает запрос
➡️в зависимости от нагрузки создает новые инстансы или перераспределяет трафик
➡️атоматически масштабируется и настраивается
* инстанс (instance) – виртуальная / физическая машина, которая обрабатывает запросы


Методы балансировки

⚪️DNS-балансировка (уровень L3)
DNS-сервер возвращает разные IP-адреса на один DNS-запрос
— не учитывает загрузку серверов и может кэшироваться клиентами (возможны задержки в обновлении маршрутов)
— например, api.example.com может вести на разные серверы

⚪️Через прокси-сервер (L7)
запросы поступают на прокси → он анализирует содержимое и перенаправляет на нужные серверы

⚪️Прямая балансировка (L4)
изменяет MAC-адреса пакетов, направляет их напрямую на backend-серверы

⚪️NAT-балансировка (L3-L4)
изменяет IP-адреса и порты пакетов, направляет трафик на разные серверы онлайн


Примеры методов для разных типов нагрузки

⭐️Статический контент (изображения, видео, CSS, JavaScript)
Пользователь запрашивает изображение с сайта
➡️ DNS-балансировщик (Nginx) направляет запрос на ближайший географически сервер CDN
➡️ CDN отдает изображение из кэша, без загрузки с основного сервера

⭐️API-запросы (REST, GraphQL)
REST API с /auth и /data:
➡️ L4-балансировщик (NAT / HAProxy) направляет трафик API на серверы, распределяет нагрузку
➡️ L7-балансировщик (Nginx) перенаправляет по URL или заголовкам:
/auth — на серверы аутентификации
/data — на серверы обработки данных

⭐️Веб-приложения (динамический контент, пользовательские сессии)
L7-балансировщик (F5 BIG-IP) с алгоритмом Sticky Sessions определяет пользователя по cookie и направляет его запросы на один сервер. Данные сессии (корзина, авторизация) не потеряются

⭐️БД
Кластер PostgreSQL с мастером и 3 репликами
➡️L4-балансировщик (например, Pgpool-II) с алгоритмом Least Connections отправляет запросы на чтение (SELECT) на реплики, чтобы снизить нагрузку на мастер
➡️запросы INSERT/UPDATE идут на мастер


📎 Материалы
1. Балансировка нагрузки: основные алгоритмы и методы
2. Load Balancer и Reverse Proxy в микросервисной архитектуре
3. Load Balancers для систем оркестрации
4. Балансировка нагрузки в Облаках
5. Сетевой балансировщик нагрузки
6. DNS Балансировка нагрузки: что это такое
7. Как работает L3 балансировщик нагрузки
8. Балансировка нагрузки на L3, L4 и L7
9. Что такое Envoy, зачем он нужен и как работает

#проектирование #инфраструктура

➿➿➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

Карта навыков BA/SA

Очередная карта навыков, найденная здесь.
Ранее мы делали собственную очень объёмную карту навыков системного аналитика.

Ну а разложить теорию в голове по полочкам и намаппить на карту навыков поможет база знаний.

Картинка без сжатия в комментариях

Микросервисы. От архитектуры до релиза

✍️ Автор: Ронни Митра, Иракли Надареишвили
🗓 Год издания: 2023
🔤 Язык: русский
📚 Объём: 336 стр.

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

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

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

Обзор книги на Хабр
Микросервисная архитектура: основные понятия

#микросервисы #архитектура

✍️ System Design

System Design (системный дизайн) — процесс проектирования архитектуры системы
🔵направлен на удовлетворение бизнес-целей, пользовательских требований и технических ограничений

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


Уровни системного дизайна

🔸 высокоуровневый (High-Level Design, HLD): общая архитектура системы, взаимодействие между компонентами, выбор технологий и структурирование сервисов
🔸низкоуровневый (Low-Level Design, LLD): детализированная информацию о компонентах системы (БД, API, структура данных и тд)


Основные принципы

🔵Масштабируемость 
Проектировать системы так, чтобы могли выдерживать рост нагрузки
➡️ Пример: горизонтальное масштабирование (добавление серверов в кластер) позволяет балансировщику нагрузки распределять трафик между ними, предотвратить перегрузки

🔵Отказоустойчивость
Минимизировать влияние отказов компонентов на всю систему
➡️ репликация БД, для достпуности данных при сбое основной БД

🔵Скорость и производительность 
Оптимизация времени отклика и обработки данных
➡️ кэширование популярных запросов с помощью Redis

🔵Модульность 
Деление системы на независимые части для упрощения разработки и поддержки
➡️ микросервисная архитектура, где каждая служба выполняет отдельную задачу (авторизация, управление товарами)

🔵Балансировка нагрузки
Распределение входящего трафика между несколькими серверами
➡️ CDN-серверы автоматически распределяют нагрузку, направляют пользователей к ближайшему серверу с кэшем

🔵Безопасность
Защита данных и ресурсов системы
➡️ шифрование данных в REST API с использованием HTTPS, механизмы защиты от SQL-инъекций, XSS и CSRF

🔵Мониторинг
Система должна предоставлять метрики для отслеживания проблем
➡️ установка инструментов мониторинга (Prometheus или Grafana)


Системный дизайн  VS архитектура

🔵системный дизайн — детальное проектирование, включая конкретные компоненты (БД, очереди сообщений, API)
❓Как именно это построить
🔵архитектура — высокоуровневое описание системы, основные компоненты, их роли и взаимосвязи
❓Что строим


Краткий пример системного дизайна

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

Сбор требований: 
🔸максимальный размер изображения — 5 МБ
🔸10 000 пользователей, 100 загрузок в секунду
🔸сохранение резервных копий

Решение
🔸API-шлюз: принимаем запросы на загрузку
🔸балансировщик нагрузки (Layer 7): распределяем запросы между серверами загрузки
🔸серверы хранения: храним изображения в S3-совместимом объектном хранилище (например, MinIO)
🔸кэш: используем CDN (Cloudflare) для ускорения
🔸очереди сообщений: RabbitMQ для обработки изображений (ресайзинг)
🔸БД: метаданные изображений сохраняем в реляционной БД (PostgreSQL)


📎 Материалы
1. Что такое System design?
2. Что такое System Design. Пример System Design для онлайн-магазина, для мобильного приложения
3. System Design для начинающих: всё, что вам нужно
4. System design. Реальный проект vs Интервью
5. System Design. Общие принцип прохождения интервью по проектированию ИТ-систем

📚 Книги
1. System Design. Подготовка к сложному интервью
2. Разработка высоконагруженных систем — очень полезная брошюра по материалам конференции HighLoad++

#архитектура #проектирование #развитие

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

⏯ Подборка новых тестовых собеседований системных аналитиков

1. Мок-интервью Бизнес Системного Аналитика на уровень Senior
2. Тестовое собеседование на позицию сеньора аналитика. Решение задач
3. Топ-10 вопросов по Системному анализу / Собеседование с разбором ответов и материалами
4. Техническое собеседование системного аналитика
5. Тестовое собеседование на позицию Middle аналитика
6. Моковое собеседование на Middle системного аналитика | Solvery & На собесе как на танцполе
7. Тестовое собеседование на младшего системного аналитика

P.S. по ссылкам выше видео с ютуба

Бонус:
1. Топ-100 вопросов на собеседовании по системному анализу
2. 120 вопросов

#собеседования

🙂 Фреймворк

Фреймворк — готовая программная структура (каркас) для разработки ПО, которая
🔘задает базовую архитектуру
🔘часто применяются в разработке мобильных, веб- и десктоп-приложений

У каждого фреймворка свой набор инструментов и свой функционал


Зачем нужен

🟣чтобы снизить время разработки за счет готовых инструментов и шаблонов
🟣для единообразие кода
🟣помогают решать базовые задачи (например, управление сессиями или безопасностью)


Виды фреймворков

🟣фронтенд: для разработки пользовательских интерфейсов
примеры: React (JavaScript), Angular (JavaScript), Vue.js (JavaScript)

🟣бэкенд: для создания серверной части приложений.
примеры: Django (Python), Spring Boot (java), Express.js (JavaScript)

🟣кроссплатформенные: можно писать код для разных платформ (iOS, Android, Windows)
примеры: Flutter (Dart), Xamarin (C#), React Native (JavaScript)


Фреймворк vs библиотека

⭕Фреймворк задает структуру и правила для разработки. Управляет выполнением кода, дает готовый каркас, который нужно достроить
⭕Библиотека: набор готовых функций, которые можно использовать по мере необходимости

⏩ Фреймворк берет управление на себя.
При использовании библиотеки контроль - у разработчика


Пример фреймворка Django

Django — фреймворк для разработки веб-приложений на Python
Состоит из:
〰️Шаблонов MVC: определяют архитектуру приложения (модели, представления, контроллеры)
〰️Модуль ORM: для работы с БД без SQL-запросов
〰️Система маршрутизации: управляет обработкой URL
〰️Встроенные инструменты: аутентификация, админ-панель, обработка форм, защита от CSRF, шаблоны HTML, API
〰️Документации

➡ Пример: создание блога на Django
Используется встроенный ORM для работы с записями, подключаются шаблоны для отображения страниц и настраивается маршрутизация для обработки URL


Минусы фреймворков

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


Как аналитик может использовать фреймворки

✅на этапе согласования требований
поможет учитывать их ограничения в согласовании требования с разработчиками
➡️Например, определять, какие задачи фреймворк решит "из коробки", а для каких нужно дорабатывать

✅ прототипирование решений
С помощью фронтенд-фреймворков (React или Angular) можно создать прототип пользовательского интерфейса
➡️для системы управления задачами сделать интерфейс с доской Kanban
Заказчик сможет протестировать функционал на раннем этапе

✅ документирование требований
В ТЗ можно указать, что бизнес-логика реализуется с использованием Django
➡️если нужно разработать REST API, можно описать, какие эндпоинты и модели данных будут поддерживаться, согласно возможностям Django REST

✅анализ интеграций
Предложить выбор подходящего фреймворка
➡️для системы обработки массивов данных поможет обосновать выбор FastAPI (высокая производительность,поддерживает асинхронную обработку запросов)
➡️при разработке архитектуры системы указать использование Spring для создания микросервисов (например, их взаимодействие через API, реализованные в Spring Boot)


📎 Материалы
1. Фреймворк
2. Что такое фреймворк: виды, задачи, правила выбора
3. Фреймворк: особенности, преимущества, архитектура
4. Что такое фреймворк и чем отличается от библиотеки, простое объяснение
5. Для чего нужен фреймворк и как его выбрать
6. Фреймворк: как выбрать подходящий для фронтэнда и бэкэнда
7. Фреймворки в веб-разработке — что это, какие существуют и для чего нужны
8. Как выбрать фреймворк для бэкенда: мнения разработчиков
9. Фреймворки — больше минусов чем плюсов
10. 5 полезных фреймворков и библиотек для начинающего фронтенд-разработчика на конец 2024 года

#инфраструктура

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу

🏦Tinkoff. Разбор задач отборочного тура трека Системный анализ

🔼 Модель зрелости REST API Леонарда Ричардсона

Модель зрелости REST API Леонарда Ричардсона — концепция, которая оценивает уровень соответствия API принципам REST
◾️показывает эволюцию от простого RPC к полноценным REST API: чем выше уровень в модели, тем лучше выстроено API

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

➿➿➿➿➿➿➿➿➿➿
💡 Напомним

URL (Uniform Resource Locator): указывает, где находится ресурс, и как к нему обратиться (например, протокол + адрес)
💙https://example.com/page

URN (Uniform Resource Name): уникальное имя ресурса, независимое от его местоположения.
💙urn:isbn:0451450523

URI (Uniform Resource Identifier): общий термин, включающий как URL, так и URN, т.е. идентификатор ресурса в сети
💙URI может быть как https://example.com, так и urn:isbn:0451450523
➿➿➿➿➿➿➿➿➿➿


Уровни зрелости модели

💙 Уровень: API как удалённый вызов процедур (RPC)
Иногда называется "болото оспы" (The Swamp of POX (Plain Old XML)

API — точка входа, которая принимает параметры и возвращает результат (единственный endpoint).
Действует как обёртка для удалённых процедур, не использует RESTful принципы

🔹один URI, один HTTP метод
🔹HTTP используется только для взаимодействия компонентов распределенной системы
🔹например, это могут быть протоколы XML-RPC и SOAP
🔹действия определяются через параметры запроса,

💙 пример: POST /api с телом запроса {action: "createUser", data: {...}}
Запросы обрабатываются как действия, а не как операции с ресурсами


💙 Уровень: Разделение ресурсов через URL

🔹несколько URI, один HTTP метод
🔹отдельные endpoints для каждого ресурса
🔹действия привязаны к URL

💙 пример: POST /createUser для получения спискапользователей, POST /getUsers для создания.


💙 Уровень: HTTP-методы

🔹несколько URI, каждый поддерживает разные HTTP методы
🔹используются методы HTTP, например, GET, POST, PUT, DELETE
🔹добавлены коды ответа HTTP (например, 200 OK, 404 Not Found). Это делает интерфейс более понятным

💙 пример:
GET /users/123 → возвращает пользователя
DELETE /users/123 → удаляет пользователя


💙 Уровень: HATEOAS для управления состоянием через ссылки

Самый высокий уровень зрелости REST API

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

HATEOAS (Hypermedia as the Engine of Application State) — характеристика веб-сервиса возвращать действия, которые могут быть выполнены с ресурсом, в виде URL
Дает возможность менять URI независимо от клиентов

💙 пример применения HATEOAS

Есть API для управления задачами в приложении
Сервер может вернуть ответ на запрос списка задач, в том числе гиперссылки
🔘self — ссылка на текущий ресурс (конкретную задачу)
🔘update — для обновления задачи
🔘delete — для удаления
Клиент может следовать ссылкам, но не знать заранее URL-структуры API

{
  "tasks": [
    {
      "id": 1,
      "title": "Buy groceries",
      "status": "pending",
      "_links": {
        "self": "/tasks/1",
        "update": "/tasks/1/update",
        "delete": "/tasks/1/delete"
      }
    },

📎 Материалы
1. А ваша служба является RESTful? Все что необходимо/обязательно знать про веб службы и REST
2. Richardson Maturity Model – RESTful API (en)
3. REST API — Что такое HATEOAS?
4. REST, что же ты такое?

#api

➿➿➿➿➿➿➿➿

🧑‍🎓 Больше полезного в базе знаний по системному анализу