Когда ты уже не джун 😀

Всем отличного начала рабочей недели, друзья! Давайте сделаем 💪🏼

#GAhahaha

🔺Use Case: ОБЫЧНЫЕ vs ИНТЕГРАЦИИ 🔺

Расскажу про отличия по пунктам шаблона Use Case.

-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.


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


ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.


ℹ️ Входные данные:
Здесь может быть ситуация, когда входные данные надо получать из внешней системы и сценарий начинается с обращения к ней. В это случае лучше текстом прописать какие данные и откуда получить.


ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.


ℹ️ Основной сценарий:

1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.

3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.

4. Внешние системы могут иметь свои ограничения. Например, если их API предоставляет меньше данных, чем нам нужно, это может стать проблемой. Наоборот, если внешняя система предоставляет слишком много информации, нам придется отбирать только необходимую.
Для этого системные аналитики описывают маппинги данных к Use Case.

ℹ️ Обработка ошибок и альтернативные сценарии:

1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.

1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.

2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.

...
-----------------------

Умение видеть и выделять интеграционные Use Cases помогает заранее поставить себе в планы на аналитику четкий объем задач, избежать проблем с оценкой времени и проблем реализации разработчиками (куча вопросов после передачи требований).

Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.

Предлагаю разобрать примеры интеграционных Use Case для TravelPoints 🙂

#ИнтеграцииGA

🧩 Интеграционный Use Case - Просмотр списка стран 🧩

В проекте #TravelPoints основной функциональностью является просмотр списка стран и отметка их посещения. Поэтому предлагаю разобрать сейчас один из них.

Казалось бы, что можно всего лишь написать 2 шага:
1. Пользователь открывает приложение.
2. Приложение отображает список стран.

Но когда мы работаем с интеграциями, то нужна детализация.

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

Обратить внимание:
1. В идеале делить задачу на части для frontend (мобильное приложение) и backend (сервер-приложение) разработчиков.
2. Посмотрите на прикрепленную картинку - на ней мини-схема архитектуры.


🧩 Use Case: Просмотр списка стран в приложении travelPoints

🔸 Пользователи:
- Пользователь МП TravelPoints


🔸 Приложения:
- МП TravelPoints
- Backend TravelPoints
- countries.trevorblades

🔸 Предусловие:
- Пользователь должен быть зарегистрирован и авторизован в приложении.
- Пользователь имеет доступ к интернету.

🔸 Цель:
Показать пользователю список полный список стран. Выделить в списке те страны, которые он посетил, если такие есть.

🔸 Основной сценарий
👇👇👇

🧩 Интеграционный Use Case - Просмотр списка стран 🧩

🔸 Основной сценарий

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

2. Мобильное приложение выполняет запрос по REST API на Backend TravelPoints

GET /countries

для получения списка стран.


3. Backend TravelPoints выполняет запрос по GraphQL API в сервис countries.trevorblades

query { countries {} }

для получения полного справочника стран.
В БД TravelPoints он не хранится, так как предполагаем, что часть параметров о странах постоянно актуализируется в countries.trevorblades и нам нужно иметь доступ к актуальной информации.


4. Полученный список стран Backend TravelPoints преобразует в структуру JSON, используемую мобильными приложениями TravelPoints, в соответствии с требованиями маппинга, и возвращает в ответ на запрос GET /countries.

В процессе преобразования Backend TravelPoints дополняет список стран информацией о том, какие страны пользователь уже посетил и сохранил, на основе данных из БД.

При формировании ответа использовать сортировку списка стран по алфавиту. Но если у пользователя есть посещенные, то отображать первые 5 те, которые он отметил как посещенные последними.

5. Мобильное приложение разбирает полученный JSON-ответ и отображает экран со списком стран пользователю.


🔸 Альтернативные сценарии к обработке:

2А. Нет доступа в сеть интернет.
3А. Внешняя система countries.trevorblades недоступна.


Простой Use Case, но именно на его примере захотелось показать детали проектирования интеграций 🙂

И в ответ на вопрос, который возник наверняка:
"А почему бы просто не сходить в countries.trevorblades из мобильного приложения напрямую за данными, или один раз не загрузить справочник?"
Да, так можно, но не всегда.

В нашем случае прямая интеграция недопустима, так как:

1. Считаем, что на стороне countries.trevorblades есть динамическая часть данных.

2. При ответе на мобильное приложение мы дополняем полученные сведения из внешней системы данными о посещенных и сохраненных в закадки странах из нашей БД (посмотрите на макет экрана).

3. И мое любимое: если API countries.trevorblades внезапно поменяется (поменяется формат запроса или ответа), то сможем быстро внести правки на бэкенде, а не страдать из-за того, что куча пользователей скачало наше мобильное приложение TravelPoints и не все обновились, в связи с чем старые версии не работают из-за чужого изменившегося API.
В этом главная суть, почему строят такие конструкции интеграций.


#ИнтеграцииGA #TravelPoints

Это того стоило 🦄

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

Каждый час расписан по минутам. Можно было заметить, что почти неделю я не вела активность в канале. А все, кто работает со мной, видят меня в работе без остановки. Сегодня ответы в мои 10 вечера, 3 ночи, 5 утра или 12 дня это норма.

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

Но в глубине души я понимаю: все это – мои инвестиции в будущее. Каждый новый день приносит мне не только испытания, но и новые возможности, новые знания, новые умения.

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

Такой ритм жизни нездоров, но пару спринтов можно пережить. Работает как со спортзалом. Если хочешь получить результат, то собери все силы, напрягись и доделай свои 100 приседаний со штангой или подобное! 😁💪

Мои усилия сегодня – это путь к чему-то большему, к мечтам и целям, которые я стремлюсь достичь 🦄

И я знаю, что уже скоро я смогу оглянуться назад и сказать себе: "Это того стоило".

P.S. Хотя бы по чуть-чуть отдыхать во время спринтов важно. Так что в бонус к перегруженному расписанию есть и приятные моменты, среди которых не только спортзал каждый день 😊 Посмотрела вот на четвертый по значимости в мире турнир по теннису. Оценила работу спортивных мобильных приложений под мероприятия 🔥 Есть новые идеи для GetAnalyst
P.S.S. Я забыла сфоткаться на фоне корта 🙈

🚀 Открыта предзапись на Интеграции систем! 🎓

Интеграции - это одно из самых востребованных направлений для аналитиков. И не удивительно. Каждая третья вакансия на hh.ru требует навыков по интеграциям, особенно в ведущих компаниях интеграторах и в продуктовых компаниях.

В программе Интеграции систем мы на практике разбираем все детали проектирования: от анализа API-документации до создания структуры требований и постановок задач на разработчиков.

🗓 Старт предобучения: 26 марта 2024

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

🎁 Специальное предложение до 24 марта: Дополнительное обучение по БД в подарок.

Хотите узнать больше? Пишите @getanalyst или заполняйте анкету предзаписи на сайте, и мы поможем оценить ваши текущие навыки и ответим на все вопросы!

🧩 Интеграционный Use Case - Просмотр информации о выбранной стране 🧩

Давайте разберем ещё пример. В нём хочу детализировать запрос к внешней системе. Но суть та жа.

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



🧩 Use Case: Просмотр информации о стране в приложении travelPoints

🔸 Пользователи:
- Пользователь МП TravelPoints

🔸 Приложения:
- МП TravelPoints
- Backend TravelPoints
- countries.trevorblades

🔸 Предусловие:
- Пользователь зарегистрирован и авторизован.
- Пользователь имеет доступ к интернету.
- Пользователь просматривает список стран: общий, избранные, недавно посещенные.

🔸 Цель:
Показать пользователю информацию о выбранной стране.

🔸 Основной сценарий:

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

2. Мобильное приложение выполняет запрос по REST API на Backend TravelPoints

GET /countries/{countryId}

для получения информации о выбранной стране из списка по её id.

3. Backend TravelPoints выполняет запрос по GraphQL API в сервис countries.trevorblades. В качестве id страны во внешней системе используется параметр code.
Id стран, используемые в travel Points и в countries.trevorblades соответствуют.

Запрос:

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

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

👉 Работаем с интерактивной API-документацией GraphQL:
🔗 https://countries.trevorblades.com/


#ИнтеграцииGA #TravelPoints
👇👇👇

🥰 Интеграционный Use Case - пример GraphQL запроса данных о стране 🥰

3. Backend TravelPoints выполняет запрос по GraphQL API в сервис countries.trevorblades для получения информации о стране по коду.

Получаем чуть больше, чем нужно согласно дизайну.

Запрос GraphQ для получения полной информации о стране:

query {
country (code: "AD") {
code
name
capital
continent {
code
name
}
currencies
phones
languages {
code
name
native
}
}
}

Подставлять и проверять здесь:
🔗 https://countries.trevorblades.com/



4. Полученный JSON-объект данных с информацией о стране по GraphQL API Backend TravelPoints преобразует в структуру JSON, используемую мобильными приложениями TravelPoints, в соответствии с требованиями маппинга, и возвращает в ответ на запрос GET /countries/{countryId}.

В процессе преобразования Backend TravelPoints дополняет страну информацией о том, была ли она сохранена в избранное, посещена, и о созданных заметках по ней на основе данных из его БД.

5. Мобильное приложение разбирает полученный JSON-ответ на запрос GET /countries/{countryId} и отображает экран со списком стран пользователю.

🔸 Альтернативные сценарии к обработке:

2А. Нет доступа в сеть интернет.
3А. Внешняя система countries.trevorblades недоступна.



Аналогичный предыдущему Use Case для закрепления материала 🙂
Далее по проекту переходим к уточнению схемы архитектуры и маппингу данных.

P.S. Хочу заметить, что можно и нужно описать короче: меньше слов, больше счастья! Для разбора поясняю всё шаг за шагом, чтобы было понятно как работает интеграция между тремя компонентами.

#ИнтеграцииGA #TravelPoints

💎 UML-Sequence в интеграциях 💎

В предыдущем обсуждении мы разобрали интеграционные Use Cases. Я использую один, чтобы показать, как UML-Sequence диаграмма может стать ценным дополнением к описанию работы системы, особенно когда речь идет о сложных интеграционных сценариях.

UML (Unified Modeling Language) — стандартизованный язык визуального моделирования, который позволяет представлять системы с различных точек зрения. UML включает в себя ряд диаграмм для решения разных задач.
Наиболее важные: UML-Sequence и UML-Activity.

UML-Sequence – это тип диаграммы, который показывает, как компоненты в системе взаимодействуют друг с другом в хронологическом порядке.

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

Применение UML-Sequence диаграммы позволяет наглядно представить этот процесс:

+ Как и когда пользователь инициирует запрос в мобильном приложении;

+ Последовательность обработки запроса между бэкендом TravelPoints и сервисом countries.trevorblades;

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

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


Пример UML-Sequence диаграммы для этого Use Case прикреплена к посту 🖼

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

Она может являться как дополнением, так и заменой текстового описания.

Основные инструменты для построения UML-диаграммы:
🔸 Draw.io (diagrams.net)
🔸 PlantUML - использован для построения прикрепленной к посту диаграммы
🔸 Microsoft Visio
🔸 Lucidchart (аналог draw.io)
🔸 Enterprise Architect

#ИнтеграцииGA #TravelPoints

🧐 Как построить UML-Sequence не зная UML? 🧐

--------------------
1. Открыть ChatGPT (инструкция тут).

2. Ввести команду:

Работай как системный аналитик. Напиши код plantUML для визуализации интеграционного UseCase в нотации UML Sequence для системы [Название системы].
[Описание Use Case]

3. Получить результат, в состав которого входит код. Скопировать код.

4. Открыть PlantUML и вставить код.

5. Готово! 🎉
--------------------

Всего 5 шагов и вы почти профи в UML! Спасибо ИИ! Экономит много времени! 😁

Не забывайте проверять за ChatGPT результаты! Он помогает в системном анализе, но не всегда может выполнить за нас работу качественно на 100%.

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

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

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

#ИнтеграцииGA #TravelPoints

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

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

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

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

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

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

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

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

💫 gRCP vs REST - ЧТО ВЫБРАТЬ ДЛЯ ПРОЕКТА 💫

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

В этом эпизоде подкаста системный аналитик Мария Кубенина, гость подкаста GetAnalyst, рассказывает про gRPC API в сравнении с REST API, и делится своим опытом использования в высоконагруженных проектах.

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

1:20 - Знакомство с Марией и её историей знакомства с gRPC API
3:30 - Почему на текущем проекте выбрали gRPC API
6:09 - Что такое gRPC и почему разработчики выбирают его, а не REST API
9:24 - HTTP 2. Сравнение gRPC и REST API. Как именовать методы gRPC
17:45 - Обновления gRPC и обратная совместимость версий. Нумерация полей в gRPC.
21:05 - Версионирование REST API
24:30 - Какие типы приложений выигрывают при переходе с REST на gRPC API
26:40 - Отмена запросов в gRPC - крутой бонус для микросервисной архитектуры
28:10 - Недостатки gRPC по сравнению с REST API
32:28 - Ограничение размера сообщений в gRPC и передача файлов
34:45 - Вызовы при внедрении gRPC в существующий проект с REST API
39:25 - Тестирование gRPC API
43:55 - Что посмотреть и почитать системному аналитику, чтобы освоить gRPC API


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

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

Подписывайтесь на подкаст и делитесь с коллегами, начинающими и опытными системными аналитиками!

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

#GAfrindlyreminder

Опыт есть опыт! 😀

#GAhahaha

Напоминаем, сегодня последний день предзаписи на программу Интеграции систем! 🎓

В программе Интеграции систем мы на практике разбираем все детали проектирования: от анализа API-документации до создания структуры требований и постановок задач на разработчиков.

🗓 Старт предобучения: 26 марта 2024

🎁 До 24 марта самые выгодные условия по подключению + курс по БД в записи в подарок!

Есть вопросы? Пишите @getanalyst или заполняйте анкету предзаписи на сайте 🙂 Мы обязательно свяжемся с вами.


P.S. В четверг вечером будет что-то важное по GraphQL API и интеграциям, запланируйте обучение на 19:00 Мск. Относится ко всем участникам сообщества GetAnalyst 👀

💎 Архитектура проекта Travel Points 💎

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

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

1. Пользователь работает с мобильным приложением (МП).
2. МП вызывает Backend, обращаясь к нему по REST API.
3. Происходит внутренняя логика:
3.1. Проверка авторизации в модуле Авторизации и регистрации.
3.2. Проверка полученных на вход параметров в модуле Основной логики Travel Points.
3.3. Вызов внешней системы через внутренний модуль интеграции с внешней системой countries.trevorblades по GraphQL.
3.4. Получение ответа модулем интеграции и преобразование полученных данных в нужный нам формат JSON и соответствующую структуру, которая используется внутри Travel Points.
3.5. Возврат ответа по итогам вызова метода REST API.
4. МП получает ответ от REST API (код HTTP + Body JSON + другие параметры, если надо).
5. МП обрабатывает ответ и располагает данные на UI как надо пользователю.

Схема архитектуры включает:
🔸 Компоненты клиентские (сайты, мобильные, десктоп приложения и другие)
🔸 Компоненты серверные (Backend, который может быть монолитом, микросервисным или другим)
🔸 Внешние системы - к которым мы подключаемся (на схеме это countries.trevorblades)
🔸 Внешние системы - которые к нам подключаются (на этой схеме нет, но это обычно приложения, которые вместе с нашими клиентами могут ходить в наш REST API, возможны другие варианты)

Это простая схема, т.к. у нас маленький проект. В полноценных проектах компонентов и API больше.

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

Для моделирования обычно используют нотацию C4, либо одну из:
ТОП-5 нотаций моделирования архитектуры

#ИнтеграцииGA #TravelPoints

💎 Архитектура С4 в structurizr - пример для TravelPoints 💎

Наиболее распространенной нотацией для моделирования архитектуры систем является C4.

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

⚫ Контекст — показывает взаимодействия между системой и её основными пользователями или другими системами.
⚫ Контейнеры — разделяет систему на контейнеры (веб-приложения, мобильные приложения, базы данных и т.д.), показывая, как они взаимодействуют друг с другом.
⚫ Компоненты — детализирует контейнеры, показывая основные компоненты системы и их взаимодействие.
⚫ Код — показыват структуру одного или нескольких компонентов на уровне кода.


Для того, чтобы построить диаграмму можно использовать draw.io или более продвинутый инструмент Structurizr.

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

Structurizr DSL (Domain Specific Language) — это специальный язык, разработанный Structurizr для описания архитектуры системы на высоком уровне. DSL позволяет архитекторам и разработчикам использовать текстовое описание для создания моделей архитектуры, которые затем можно визуализировать с помощью инструментов Structurizr. Это текстовый формат, который легко читается как людьми, так и машинами, что делает его удобным для контроля версий и совместной работы в команде.


Пример кода вашей первой диаграммы в Structurizr 👇 Попробуйте сделать то же, что на картинке к посту!

#ИнтеграцииGA #TravelPoints

💎 Архитектура С4 в structurizr - пример для TravelPoints 💎

Инструкция:
1. Открыть https://www.structurizr.com/dsl
2. Очистить область с кодом слева.
3. Вставить код из этого поста.
4. Нажать кнопку "Render" сверху над окном с кодом.
5. Готово!

workspace {

model {
user = person "Пользователь" "Использует мобильное приложение Travel Points для управления баллами путешествий."

TravelPoints = softwareSystem "TravelPoints" "Система для путешественников." {
mobileAppiOS = container "Мобильное приложение iOS" "Интерфейс для клиентов." "iOS"
mobileAppAndroid = container "Мобильное приложение Andriod" "Интерфейс для клиентов." "Andriod"
backend = container "Backend" "Обрабатывает бизнес-логику, содержит сервисы и базы данных." "Server-side Application"
}

countriesTrevorblades = softwareSystem "Справочник стран" "Внешняя система."

user -> mobileAppiOS "Использует"
user -> mobileAppAndroid "Использует"
mobileAppiOS -> backend "REST API"
mobileAppAndroid -> backend "REST API"
backend -> countriesTrevorblades "GraphQL"
}

views {
container TravelPoints {
include *
autolayout lr
}

theme default
}
}

#ИнтеграцииGA #TravelPoints

📹 Практический вебинар: GraphQL + Postman + Интеграции 📹

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

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

Чтобы передать вам знания о GraphQL на практике, мы готовим для вас уникальный вебинар:

🌟 Интеграции: знакомство с GraphQL через Postman
🗓 28 марта, в 19:00 Мск (чт)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

За один вечер:
🟢 Узнаете как работать с задачами на интеграции систем
🟢 Получите базовые знания по GraphQL API, и понимание, как применить их в работе системного аналитика
🟢 Освоите инструмент тестирования API Postman
🟢 Самостоятельно будете проверять методы GraphQL API в прямом эфире

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

Готовы освоить GraphQL + Postman + Интеграции?
Регистрируйтесь, чтобы не пропустить! 😉

🧩👀 Самое сложное при проектировании интеграций смотреть на систему с нескольких сторон.
Есть техническая и пользовательская часть. И под капотом всегда происходит какая-то магия. Давайте разберёмся.

Для экрана со списком стран мобильного приложения #TravelPoints нужно сделать REST API метод (часть Backend), чтобы получать данные от сервера. Этот список оригинально возвращается из внешней системы countries.trevorblades по GraphQL. Хочу погрузиться в эту конкретную задачу.

Обращаю внимание! Я отделила задачу Backend от Frontend. Я не буду описывать как иконки на экране располагать. Это чистая интеграционная задача, на интеграционный REST API метод. При этом Frontend в голове всё равно держу, т.к. Backend должен отработать для Frontend 🤯

Для работы с детализацией ИНТЕГРАЦИОННОЙ ЗАДАЧИ на Backend я использую эти мини-чеклисты аналитики и проектирования.

📌 ЧЕК-ЛИСТ АНАЛИТИКИ
1️⃣ Получить макеты UI всех наших клиентов (хотя бы черновые)
2️⃣ Проверить базу данных нашей системы
3️⃣ Проверить API внешней системы в части данных, включая тестирование через Postman при возможности
4️⃣ Проверить API внешней системы в части безопасности (авторизация, роли, и т.д.).

📌 ЧЕК-ЛИСТ ПРОЕКТИРОВАНИЯ
1️⃣ Описать интеграционный Use Case для работы метода, именно части backend: от данных на вход до результирующих данных на выход.
2️⃣ Спроектировать вид нашего JSON (или другого формата сообщений). Можно просто структуру. Описать русским текстом. Этого достаточно. Разработчики доведут до формата JSON, если экспертизы у аналитиков нет.
3️⃣ Сделать маппинг данных: наш API метод + наша БД + внешний API.
4️⃣ Дополнительно:
+ добавить схему архитектуры,
+ сослаться на статью “как тут работает авторизация и какая ролевая модель во внешней системе”,
+ добавить UML.

Готово!

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

#ИнтеграцииGA