🔥 REST API: заполненный шаблон постановки задачи 🔥

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

Поэтому я подготовила для вас пример постановки задачи на REST API метод.


1️⃣ Шаблон постановки задачи — с ним:
✔️ на старте видишь все обязательные блоки по задаче, которые надо заполнить для разработчиков
✔️ проще, чем каждый раз начинать задачу с чистого листа
✔️ вся команда всегда чётко знает, где и в каком месте располагается каждая часть требования к REST API методу


2️⃣ Пример использования шаблона поможет:
✔️ быстро увидеть, как заполняются все разделы на реальном кейсе
✔️ понять JSON-структуру, как строится метод и маппинг данных
✔️ избежать типичных ошибок с "не учел" и "не продумал"


Шаблон постановки задачи на REST API метод описан в этой статье.

📥 А к посту прикреплен документ из Confluence:
пример использования шаблона для метода GET /recipes/{recipeId} - получения рецепта по id для экрана просмотра рецепта на проекте #RecipeGA

Сохраняем и пользуемся 🤍


#RestApiGA

Если бы майские выходные были фичей, это был бы самый долгожданный релиз года 🥳

Release notes:
«Добавлена долгожданная функция безопасного отключения от рабочих чатов, алерты мониторинга пересылаются в никуда, а уровень кофеина падает до безопасного для сна».

Всем классных выходных!
Ваша команда GetAnalyst ☀️

👉📚 7 шаблонов архитектуры, которые важно знать СА 📚

Системный аналитик описывает внутреннюю логику приложений:
+ связи между UI (экранами), БД и API
+ интеграции с внешними системами
+ алгоритмы обработки данных
+ и другие технические детали

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

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

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


👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно знать и понимать СА:

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)


Все подробности, примеры и иллюстрации — в мини-книге, прикреплённой к посту 🙌📚

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

✅ Все компоненты архитектуры: шпаргалка для системных аналитиков и архитекторов ✅

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

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

При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, API или SDK.

Frontend-компоненты:

🖥 Сайты — информационные веб-страницы, без функций управления данными, только чтение. Дополнительно могут работать с заявками, управлением контентом (CMS), минималистичными ЛК пользователей и приемом платежей.

📱 Мобильные приложения — нативные (iOS, Android) или кросс‑платформенные (Flutter/React Native) клиенты с доступом к датчикам и оборудованию устройства, офлайн‑кэшем и пуш‑уведомлениями.

🖥 Веб-приложения — одно‑ или многостраничные приложения, работающие в браузере. Могут устанавливаться на сервера как независимо от Backend, так и включать в себя Backend (монолиты).

💻 Десктоп-приложения — устанавливаемые на компьютер программы, которые получают доступ к файловой системе, драйверам, оборудованию, и могут работать оффлайн. Например, редакторы фотографий, приложения банкоматов, кассы.

🔗 Виджеты — встраиваемые мини‑приложения (JS/iframe‑компоненты), добавляющие отдельную функцию в чужой интерфейс, без изменения кода и полного перезапуска той системы, куда они встраиваются.

Backend-компоненты:

🔹 Монолит — единое backend-приложение, где все логические модули системы организованы в одной общей кодовой базе. Деплоится и масштабируется только целиком, нельзя обновить только отдельный модуль внутри монолита. Обычно имеет только одну БД со всеми данными в ней.

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

🔹 Микросервисы — небольшой автономный сервис, владеющий узким бизнес‑контекстом, меньшим, чем у обычных сервисов, и (часто) со своей БД. Деплоится и масштабируется независимо от остальных сервисов.

🔹 API Gateway — единая точка входа в Backend-приложение с архитектурой из сервисов или микросервисов. Отвечает за маршрутизацию запросов в нужные сервисы, может выполнять функции аутентификации и авторизации, проверять лимиты по запросам от клиентов, выполнять агрегацию и трансформацию ответов, кэшировать данные и собирать метрики для мониторинга.

🔹 Базы данных (БД) — отвечают за хранение текстовых данных в определенной структуре: реляционные (PostgreSQL, Oracle и другие), NoSQL, time‑series.

🔹 Файловое хранилище (ФХ) — компонент, отвечающий за долговременное хранение документов, фото, медиа и других файлов системы.

🔹 Брокеры сообщений — асинхронный обмен сообщениями (Kafka, RabbitMQ и другие).

🔹 Шина данных, ESB (Enterprise Service Bus) — интеграционная шина уровня предприятия, которая объединяет разнородные приложения через единый коммуникационный слой и «умную» посредническую логику. Типична для SOA архитектуры.

🩶 Внешние системы — платёжные системы, CRM, ЭДО и другие системы, с которыми нужна интеграция.

Hardware-компоненты:

🎥 Камеры
🖨 Принтеры, чековые терминалы
💳 Считыватели банковских карт
🎙 Микрофоны
📦 RFID/Barcode‑сканеры
🌡 IoT‑датчики (температура, влажность, движение).
и другие.



Используйте этот перечень как чек‑лист.

Он гарантирует, что в архитектурном описании не останется «слепых зон».
Каждый компонент должен быть явно показан на схеме — например, в нотации C4.

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