Быть честными - важно. Главное не переусердствовать.
И без инцидентов с БД, пожалуйста 🤣

Всем привет!

У нас переезд между почтовыми сервисами и нестабильно уходят письма 😔

🟢 Микросервисы: от бизнес-процессов до интеграционного взаимодействия
🌟Сегодня в 18:00 Мск - ссылка на вебинарную комнату:
https://pruffme.com/webinar/?id=f5dbe802611de4369f61521c1d91dd8d

Доп. повторы организуем завтра в 15:00 и 19 Мск, т.к. не всем пришла ссылка на трансляцию. Благодарю за понимание 🙏

Hello! ☀️ Открываем новую неделю с диаграммы контейнеров C4.

Предыстория:
1. Сделали схему архитектуру в моей упрощенной нотации CloudRectangle.
2. Сделали самый верхний уровень архитектуры в нотации С4 - Context.

Container С4:
Углубляет представление системы, описывая основные части, или "контейнеры" (backend-приложение, веб-приложение, мобильного приложение, базы данных, файловая система), которые входят в состав системы.
На этом уровне определены функции каждого контейнера, технологические решения по языкам программирования, протоколы взаимодействия.


Что получилось в результате по примеру с нашим проектом системы для Зоомагазина PetCo:

1️⃣ PetCo Online был синим прямоугольником на уровне Context. Мобильных приложений, сайта, бэкенда отдельно не было. Теперь они появились. И синий прямоугольник превратился в детализированый пунктирный.
Пока сделала админку как наше отдельное новое приложение, существующую систему PetStore для касс в магазине пока не трогаем.

2️⃣ До этого ни про какие API речи не было. Сейчас на стрелках указаны техногологии, по которым системы, подсистемы или отдельные приложения взаимодействуют друг с другом: REST API, HTTPS, SMTP, SOAP, GraphQL и другие.
Аналитик может указывать это самостоятельно в 80% случаев (когда не библиотеки и когда не описываются протоколы взаимодействия с БД - это уже к архитекторам и программистам).

3️⃣ Появились технологии разработки - указаны языки программирования, на которых создаются наши приложения - Java, Swift, Kotlin.
Это то, что аналитик указывает, если знает. Если я не знаю, то обычно указываю на схеме ???, чтобы потом дополнили разработчики.

4️⃣ Появились базы данных с указанием технологий (Oracle, PostgreSQL, MongoDB и др.).

5️⃣ Убрала двух серых пользователей, т.к. они уже никакой смысловой нагрузки не несут. Я рассказываю на этом уровне C4 Container про новую систему PetCo Online, которую мы делаем.


Результат появился в Miro PetCo - ваш шаблон по C4 Container 😉

❗️Начинаем через 15 минут❗️


🟢 Микросервисы: от бизнес-процессов до интеграционного взаимодействия
🌟 15:00 Мск - ссылка на вебинарную комнату:
https://pruffme.com/webinar/?id=f5dbe802611de4369f61521c1d91dd8d

* в 19:00 на трансляцию можно попасть по этой же ссылке

Присоединяйтесь! Повторов больше не будет!

Почему я делала шаблон C4 в Miro?

1. Draw.io классный, но есть еще варианты инструментов для создания схем архитектуры. Почему бы не показать их вам? Больше возможностей всегда хорошо!

2. Мне более приятен интерфейс Miro. Но при этом я продолжаю использовать в основном Draw Io. Зависит от предпочтений ваших и команды.

3. Теперь вы можете скопировать этот шаблон себе ❤️ и использовать для создания C4 в Miro на вашем проекте!
Как это сделать? Смотрите на картинку к посту.

Добавляйте шаблон в избранное или делайте личную копию, которую можно редактировать 🙌 Практикуйте C4 и пополняйте свое портфолио по работе с интеграциями и архитектурой - востребованными навыками для системных аналитиков сегодня!

Внутри компании нет роста, нет задач для практики, сижу на одном месте, на собеседованиях чувствую страх, неуверенность и синдром самозванца 😞Знакомые чувства?

Особенно грустно, когда талантливые аналитики ждут повышения на текущем месте работы от руководителя, но ничего не происходит. Просить? Нет. В голове ведь: "а что если...уволят/понизят?".

Обычно случается следующее:
1. Аналитик открывает вакансии.
2. Проверяет, каких навыков не хватает и строит план по их получению.
3. Подтягивает знания любыми доступными способами, пополняет портфолио.
Обучение может через практику быть в рамках работы, если все же хоть как-то можно получить доступ к более сложным задачам и проектам. Или дополнительное образование.
4. Обновляет резюме и публикует.

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

Что можно получить в результате усердной работы и понятной цели?
🔹 Junior -> Senior.
🔹 +100к.
Junior -> Senior кейс скорее исключительный, когда нашего коллегу очень долго не повышали. Но прорыв серьезный! И это показатель - всё возможно, если прикладывать усилия!

Спасибо, что пишете! Такая обратная связь вдохновляет не только меня, но и ваших коллег ❤️

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

🧩 Интеграционные Use Cases: что это? 🧩

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

Функциональные требования определяют, ЧТО система должна делать.
Это специфические описания возможностей или характеристик системы, которые влияют на ее поведение.
Пример: "Система должна предоставлять возможность пользователям регистрироваться, используя адрес электронной почты".

Use Case (или сценарий использования) описывает, КАК и в КАКОМ ПОРЯДКЕ эти функциональные требования реализуются в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий "Регистрация нового пользователя", который будет включать в себя шаги по вводу данных, их валидации, отправке подтверждения на email и так далее.


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


Что из себя представляет интеграционный Use Case?

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


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

✨Интеграционные Use Case: проект для онлайн Зоомагазина PetCo ✨

Для примера, я хочу выделить Use Cases, связанные с функциями создания онлайн-заказов и приемом онлайн-платежей за них через Интернет-эквайринг Raif Pay.


1. Создание онлайн-заказа с последующей синхронизацией данных с бэкендом PetStore.
Пользователь может сделать заказ через мобильное приложение или веб-приложение. Эти данные, после ввода, синхронизируются с бэкендом petStore.


Предусловие: Пользователь выбирает товары, добавляет их в корзину и оформляет заказ.

Роли:
+ Пользователь-покупатель

Приложения и сервисы:
+ Мобильное / веб-приложение
+ Бэкенд PetCo:
+++ Сервис Основной Бизнес-логики,
+++ Сервис интеграции с PetStore
+ Внешняя система PetStore (бэкенд)

Входные данные:
+ Список товаров
+ Количество каждого товара + цены
+ Данные пользователя (адрес доставки, контактные данные и др.)

Результат:
+ Заказ создан в системе PetCo - в Основной БД
+ Заказ синхронизирован с бэкендом PetStore
Статус товара "Создан (ожидает платеж)

Основной сценарий:
👩‍💻To Be Done

Обработка ошибок и альтернативные сценарии:
👩‍💻 To Be Done


2. Проведение онлайн-платежа за заказ через Raif Pay в мобильном приложении PetCo.
После создания заказа, пользователю предоставляется возможность оплатить его онлайн через платежную систему Raif Pay.
👩‍💻 To Be Done


3. Синхронизация статуса оплаты между бэкендом PetCo, Raif Pay и бэкендом PetStore.
После того как оплата прошла через Raif Pay, информация о статусе оплаты отправляется обратно на бэкенд PetCo и PetStore. Этот шаг важен для обеспечения консистентности (соответствия) данных между системами.
👩‍💻 To Be Done


4. Уведомление пользователя о статусе заказа и оплаты.
После завершения заказа и оплаты, пользователю автоматически отправляется уведомление о текущем статусе его заказа и результате оплаты на email.
👩‍💻 To Be Done


P.S. Есть дополнения или мысли по сценариям Use Cases, которые могут относиться к интеграциям в рамках оформления и оплаты заказов - пишите в комментарии!

🧩 Почему интеграционные Use Cases важны? 🧩


В процессе интеграций всегда есть минимум два участника:

🔹Наша система - которая отвечает за работу сценария, реализует его логику. БОльшая часть интеграций, с которыми мы сегодня работаем, реализована на бэкенде.
По нашей схеме компонентов C4 для PetCo это видно для взаимодействия с Raif Pay и бэкендом PetStore (посмотрите внимательно связи на уровне контейнеров и компонентов).
Также важно понимать, что и к нам могут интегрироваться. Для этого мы в проектах разрабатываем программные интерфейсы (например REST API, GraphQL, gRPC или другие).

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



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

🔺Точки отказа:
Интеграции могут стать "узким местом". Проблемы соединения, задержки в ответах на запросы во внешние системы или даже их полное отсутствие могут серьезно повлиять на работу нашего приложения.

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

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

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


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


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

🗓 Планы на ближайшую неделю 🗓


1️⃣ Завтра проводим воркшоп по проектироваию микросервисов, с 18 до 21 Мск.

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

А мы с Никитой поможем им шаг за шагом пройти этот путь.

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


2️⃣ 31 августа завершается запись по сниженной цене на осенний поток по проектированию Интеграций.

3️⃣ Встречаем осень!
Готовим для вас необычную практику с включением с микрофонами в онлайн на следующей неделе. В пятницу будет анонс 😎

3️⃣ И снова 3 сентября 😁


Осень - время учиться и получать крутые результаты ⚡️🚀 И мы с вами ее встречаем очень бодро!

🧩 Анализ API-документации RaifPay

Первое, что вы должны сделать, когда только получили документацию - прочитать ее по диагонали. Ниже моя краткая инструкция по чтению API-документации.

Показываю, как применять ее на примере знакомства с API-документацией RaifPay.
🧩 https://pay.raif.ru/doc/ecom.html#section/Podklyuchenie-k-ekvajringu


1️⃣ Посмотреть оглавление. Найти разделы, в которых потенциально есть информация по следующим пунктам из этой инструкции.
Это не PDF-файл, а веб-страница. Оглавление в левой стороне. На скрине выделила разделы, которые меня с ходу заинтересовали. Еще ниже есть справочник по ошибкам, на скрине его нет.


2️⃣ Авторизация и аутентификация.
Обычно эта информация во введении. Но тут во введении из полезного:

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

Начала раскрывать подразделы сожержания и нашла требования к авторизации в API.

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



3️⃣ Тестовые доступы, если еще не получили.
В требованиях к авторизации:
Прод: https://pay.raif.ru
Тест: https://pay-test.raif.ru
Для генерации тестового секретного ключа необходимо обратиться по адресу: ecom@raiffeisen.ru
😄 Придется срочно писать в поддержку, чтобы мне включили тестовый ключ в ЛК.
Кстати, это сделано для того, чтобы тестовые сервера не убивали высокой нагрузкой. Поэтому редко можно найти открытый API для тестирования.

В разделе тестирования:
Для полного цикла тестирования оплаты необходимо указывать сумму платежа больше 10 рублей. Карты для тестовой среды:
4000001000000018 12/24 880 - с 3DS пин для успешной оплаты 1234, для получения ошибки 1111



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

🧩 Анализ API-документации RaifPay


4️⃣ Рекомендации по использованию. Примеры сценариев использования.
Это не всегда есть в API-документации. Но если есть, то считайте, что задача почти готова - предложенный сценарий интеграции надо адаптировать под бизнес-процессы текущего проекта.

В API Raif Pay всё вау! С UML-схемой по интеграции нам предложили типовой сценарий интеграции в разделе Схема работы. Дело за малым - просто перенести его в свои требования и сделать маппинг данных ❤️


5️⃣ Общие требования к обработке ошибок. Коды ответов.
Нашла два раздела: в API, и отдельный справочник ошибок.
Посмотрела. Буду иметь ввиду. Вернусь в эти места на этапе детальной проработки требований.


6️⃣ Список методов, необходимых для реализации интеграционных сценариев, и документацию по ним.
На этапе знакомства с документацией сильно вчитываться не надо. Главное понять, что методов для реализации бизнес-процессов текущего проекта достаточно.

Все методы API описаны в разделе Методы API.
Просматриваю в общем структуру запросов-ответов, названия методов, вспоминаю прочинанную схему работы. Всё. Пазл сложился! Можно описывать интеграционные Use Cases по приему платежей через Raif Pay

P.S. И писать им письмо, чтобы дали тестовый доступ GetAnalyst 😎
Это подсказка - на реальном проекте, пока пишете сценарий, аналогично можно запрашивать и ждать доступы, чтобы распараллелить задачи и потом не ждать их долго, когда закончите с описанием.
После описания сценариев с полученными доступами будете проверять API, чтобы сделать маппинг данных идеальным, понять до конца работу API и уточнить описанный сценарий, где необходимо 🤝

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

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

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

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


🎯 Сидишь в одном месте, копаешься в своей системе, и кажется, что всё под контролем. Но ведь у каждого своя система, свои "баги" и "фичи". Что если завтра тебе придется работать с чем-то новым? Ты готов?

🎯 Новый опыт — это не просто строчка в резюме. Это твой новый уровень. Ведь когда ты знаешь, как "говорят" между собой разные системы, ты как переводчик на переговорах между странами. Важная роль, верно? 😉

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


Учись, получай опыт по интеграциям, подписывайся на полезные каналы по системному анализу, читай книги и статьи. Это всё в совокупности поможет достичь больших целей в профессии и отключит "синдром самозванца" ❤️🧩

Сила интеграций! 💪

Отправила письмо в тех.поддержку Raif Pay, чтобы получить тестовый доступ. Мне пришел автоответ. И, как Вы понимаете, у них автоматически создалась задача в jira по моему обращению.

Т.е. логика такая:
1. При получении письма на определенный электронный адрес вызывается API Jira для создания задач.
2. Создается задача.
3. Присвоенный номер задачи берется из ответа и подставляется в письмо-автоответ.
4. Письмо автоответ отправляется человеку, который отправил запрос в тех поддержку.

Просто, но приятный сервис. Забота о клиентах 💪 Ставим Like ❤️ Raif Pay и надеемся, что они дадут нам API-ключ на тестовую площадку с лимитами на запросы 🙏

Мем смешной, а ситуация страшная 🤡

🧩 Анализ API-документации PetStore

Закрепляем пройденный материал еще одной практикой по анализу документации REST API. Если для RaifPay документация похожа на самописную web-страницу или созданную на основе Postman, то для создания документации на внешнюю систему PetStore разработчики использовали популярный инструмент документирования API Swagger.

Делаем первичный анализ по инструкции:

1️⃣ Посмотреть оглавление.
Swagger-документация стандартная. Сначала идет общее описание API, требований к авторизации, описание боевых и тестовых площадок, а затем список методов. Список методов какого-то строгого подхода к порядку не имеет.


2️⃣ Авторизация и аутентификация.
Обычно эта информация во введении. Из полезного:

For this sample, you can use the api key special-key to test the authorization filters.
Если по-русски - special-key наш секретный ключ. Подставляем для тестирования и радуемся, что все работает.


3️⃣ Тестовые доступы.
В этой документации нет переключения между прощадками. Но обычно в Swagger-документации есть раздел Servers.
Пример: https://app.swaggerhub.com/apis-docs/TestOrg_Brahmdev/Celerity/1.0.0
Про секретный ключ для тестов я уже написала в п.2.


4️⃣ Рекомендации по использованию API.
Как я и говорила ранее - отсутствуют. Поэтому придется догадываться логически.
В реальной жизния я обычно иду тестировать UI внешней системы, если он есть. Так и разбираюсь какой метод за каким должен идти.
Часто для этого использую консоль браузера.


5️⃣ Общие требования к обработке ошибок.
Общих требований нет. Указаны под каждым запросом отдельно. Это стадартно для Swagger-документации.


6️⃣ Список методов.
Начиная с POST /pet/{petId}/uploadImage - uploads an image и далее идет список методов.
Раздел Models стандартный - описывает структуру объектов.

Больше разных Swagger API документаций в открытом доступе можно найти здесь.

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

🍎 Use Case: Подготовка к линейке 1 сентября 📚

Выберите ваш текущий статус:

❤️ Пользователи: Родитель ученика 1-го класса.
Основной сценарий: Собрать рюкзак, причесать ребенка, убедиться, что школьная форма чистая.

👍 Пользователи: Родитель ученика 5-9 класса.
Основной сценарий: Напомнить о том, что "лето не вечно" и "учёба - это твоё будущее".

🔥 Пользователи: Родитель старшеклассника.
Основной сценарий: Попробовать вытащить подростка из-под одеяла до обеда и надеяться, что он сам соберется.

😄 Пользователи: Системный аналитик уже забывший о школе.
Основной сценарий: Сделать еще один глоток кофе и продолжить работать, поздравив коллег с началом учебного года.

Отметьте ваш вариант реакцией и поделитесь, как вы справляетесь с подготовкой к 1 сентября! 🧩🤝🌪

Интеграционный Use Case, если не погружаться в детали 🙈

Продолжаем работу с интеграционными Use Cases. Пора их детализировать.


1. Use Case: Создание онлайн-заказа с последующей синхронизацией данных с бэкендом PetStore

Роли:
+ Пользователь-покупатель

Приложения и сервисы:
+ Мобильное / веб-приложение
+ Бэкенд PetCo:
+++ Сервис Основной Бизнес-логики,
+++ Сервис интеграции с PetStore
+ Внешняя система PetStore (бэкенд)

Входные данные:
+ Список товаров
+ Количество каждого товара + цены
+ Данные пользователя (адрес доставки, контактные данные и др.)

Результат:
+ Заказ создан в системе PetCo - в Основной БД.
+ Заказ синхронизирован с бэкендом PetStore - он отображается в приложениях PetStore.
Статус товара "Создан (ожидает платеж)

Предусловие:
Пользователь добавил товары в корзину, выбрал животных.

Основной сценарий:
1. Пользователь переходит в корзину и выбирает "Оформить заказ".
2. Приложение (мобильное или веб) показывает общую стоимость заказа и предлагает пользователю ввести адрес доставки и контактные данные.
3. Пользователь вводит необходимые данные и подтверждает заказ.
4. Заказ создается в системе PetCo в статусе "Новый".
5. Заказ синхронизируется с внешней системой PetStore (бэкенд). Пользователи PetStore видят его в своих приложениях.
6. Приложение информирует пользователя об успешном создании заказа. Пользователь может переходить к его оплате.

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