🍁 В детстве мне казалось, что мы празднуем два Новых Года: 1 Сентября и 1 Января. Оба праздника и сейчас заставляют задуматься о возможных переменах в жизни, о новом этапе в развитии 🌱🙌

В недавно прочитанной книге Кармин Галло мне понравилась фраза:

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

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

👉 Вы уже с нами, в сообществе GetAnalyst, а значит по умолчанию думаете о своём развитии и растете в знаниях. А я здесь, чтобы помочь вам идти вперед и поддержать на пути, любыми способами.

У тебя всё получится, помни об этом!

Ценю вас. Верю в каждого из вас. Вы лучшие!

С Новым Годом С Днем Знаний! 📚🍁

⚡️ Часть 3. Выделяем микросервисы: разбор примера для #RideFlow ⚡️

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

6. После завершения поездки
6.1. Заказ переводится в статус выполненного.
6.2. Рассчитывается сумма для выплаты водителю и переводится ему на баланс.
6.3. С пользователя собирается обратная связь - оценка поездки.

Подойдут сервисы, которые выделили ранее:
🔸 Сервис “Заказы” - для смены статуса заказа
🔸 Сервис “Уведомления” - для рассылки уведомлений о необходимости собрать отзывы по заказу
🔸 Микросервис “Калькулятор стоимости поездки” - для расчета суммы выплаты водителю

И нужен будет новый сервис
🔸 Микросервис “Выплаты водителям” - через него будут проводиться выплаты водителям, хранение информации по их банковским реквизитам и учету “ЗП”.

7. Выплаты водителям
В конце суток, раз в 24 часа, производятся выплаты водителям на их банковские счета, с формированием платежных документов, которые отправляются на email водителям и доступны для загрузки в их приложениях в формате PDF.

Здесь нужны:
🔸 Микросервис “Выплаты водителям”
🔸 Сервис “Уведомления” - для рассылки уведомлений об успешных выплатах с PDF

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


В конце описания системы такси есть дополнительные требования по администрированию системы, из которых можно выделить 🔸сервис “Админка”, 🔸сервис “Чат поддержки” и 🔸сервис “Диспетчерская”.

На этом разбор примера выделения микросервисов можно завершать. Осталось собрать полученные результаты в единую схему архитектуры 🙂🏛

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

🗡 Сервис или Микросервис? 🗡

Почему в разобранном примере (предыдущий пост + эти) в одном месте я писала “сервис”, а в других “микросервис”? Почему “Сервис уведомлений”, но “Микросервис Калькулятор стоимости поездки”?

🟪 Микросервисы (МС):
✔️ Маленькие, как правило управляют одним объектом данных (только водитель, только машина, или только пассажир), делают одну задачу или обслуживают один процесс
✔️ Своя независимая БД
При выделении микросервисов есть одна проблема - не перейти на наносервисы, которые делают одну задачу, и при этом их вызывают редко. Это не нужно.

🟪 Сервисы:
✔️ Больше, чем МС. Могут иметь много логики внутри, отвечать за разные данные (делать все сразу для данных о водителях, машинах и пассажирах), делать разные задачи и выполнять несколько схожих процессов.
✔️ Может быть своя независимая БД, а могут использовать общую на несколько сервисов.
Сервисы - это мини-монолиты 😅 Так что по сравнению с микросервисами проблема другая - вовремя остановиться и не сделать большой монолит.


Если говорить в целом о подходах микросервисной архитектуры (MSA) и сервис-ориентированной архитектуры (SOA), то отличий будет больше:
- разные шаблоны проектирования,
- организации хранения данных по отдельным БД и схемам,
- разные способы интеграции сервисов и микроервисов внутри проекта - шина, API Gateway, прямые вызовы по API и другие.


👉 Называть в проекте отдельное сервер-приложение сервисом или микросервисом - зависит от понимания принципов архитектуры всей командой. Я видела когда сервисы называли микросервисами; когда всё подряд в проекте называли сервисами, но знали, что работает как микросервис, а что как сервис.

Считаю, что желательно стремиться к общепринятым и понятным всем именованиям компонентов в архитектуре проекта. Чтобы при подключении новых сотрудников к проекту не получать каждый раз одни и те же вопросы “А почему так?”

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

🤖 ChatGPT для проектирования БД 🤖

Использование нейросетей для работы над проектами, в частности ChatGPT, всё еще может вызывать вопросы. Где-то это помогает, а где-то наоборот отнимает время. Также есть проблема - нейросети не всегда правы. И если неопытный аналитик пытается использовать их бездумно, то ошибки 100% будут.

Но в то же время, если вы используете нейросети:
✔️ Умея решать задачи по аналитике самостоятельно
✔️ Зная алгоритмы работы и последовательности команд
✔️ Используя правильные связки инструментов
то нейросеть может стать вашим помощником! 🤝

Если вы умеете проектировать БД на логическом уровне, ищите возможность развиваться в темах БД и SQL, и хотите ускорять свою работу с использованием нейросетей, то приглашаю вас на онлайн-практику:

🟡 Использование ChatGPT для проектирования БД
📆 5 сентября, четверг
🕘 19:00 - 21:30 МСК
Подробности и запись

План:
1. Знакомство с ChatGPT
2. Проектирование физической модели БД PostgreSQL
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов
4. Создание реальной БД и SQL-запросы в DBeaver

Запись будет доступна по окончании занятия. А пока ждем четверга, можно посмотреть занятие в записи по написанию SQL-запросов с практикой в реальной БД через DBeaver 😎

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

Когда мы делим монолит на микросервисы, то процесс обмена данными в проекте усложняется. Другими словами: алгоритмы усложняются и простые Use Case становятся интеграционными.


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

В микросервисах дополнительно нужны API для внутренних взаимодействий между ними. У каждого микросервиса свой API.

Для внутренних взаимодействий часто выбирают gRPC / GraphQL, оставляя для UI и других взаимодействий за пределами сервера популярный REST API.


2️⃣ Нужно выбрать подход к взаимодействию сервисов и микросервисов в проекте. Основные:

✔️ API-Gateway: единая точка входа для всех запросов от клиентов, направляет их к соответствующим микросервисам

✔️ Хореография: сервисы обмениваются событиями напрямую, принимая решения на основе полученных событий

✔️ Оркестрация: один сервис (оркестратор) управляет вызовами к другим сервисам, контролируя весь процесс выполнения задачи

✔️ Шина данных (Enterprise Service Bus, обычно для SOA): направляет сообщения между сервисами, преобразует данные и выполняет оркестрацию процессов

✔️ Очереди сообщений, как Kafka и RabbitMQ: для асинхронного взаимодействия и гарантии доставки и их обработки сервисами

Без подхода - будет паутина связей. Да и с ним тоже, честно говоря



👉 На картинке к посту:

🔸 Выбран подход с API-Gateway
Просто предствьте что будет, если убрать эти три API-Gateway в левой части. Когда приложения с UI будут сами выбирать какой микросервис вызывать и вызывать их API напрямую 🥲

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


❗️Эта реализация - общий вид, черновик. Далее нужно добавлять БД, выбирать API, делать вычитку требований и описание процессов, чтобы проверить взаимодействия. Делать C4.

Cхема показывает:
- МСА это не сложно, но трудоемко
- Чем меньше МС, тем лучше и проще 😃

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

⚡ Виды API и их назначение: когда и какой выбрать ⚡

API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.

Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface).


Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket


В деталях 👇

⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).

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

Пример документации:
Wildberries


⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.

Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.

Пример документации:
PayPal (обратите внимание, что устаревший)


Самые интересные API с примерами документации чуть позже 😉👇

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

⚡ Виды API: GraphQL, gRPC, WebSocket ⚡

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

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

Пример документации:
Contentful


⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.

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

Пример документации:
Dropbox от Google


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

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

Пример документации:
Binance Биржа


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

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

🤖 Интеграция по API с нейросетью или с геокодером? 🗺

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

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

В итоге у меня возникла дилемма…


🤖 Нейросети - интеграция по REST API или gRPC
Сначала мне показалось это прекрасной идеей, пока я не поняла, что никакого бизнес-смысла у задачи не получится.

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

Так еще и сложно в тестировании местами, особенно с процессом регистрации и авторизации запросов.


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

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


🧼 Интеграция по SOAP API
У меня давно просят показать особенности работы аналитика с SOAP, с форматом XML, и есть отличный демо-API для управления пользователями системы.


Хочется всё, но так не получится.
Поэтому хочу обратиться к вам за помощью в выборе 🙏

Голосование 👇

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


Пример:

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

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

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

Похоже на маленький ад 🥲

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

Основные способы интеграции:
▫️ API и Библиотеки
▫️ Очереди сообщений и брокеры
▫️ Файлы
▫️ Общая БД


📚 Подробнее о том, что такое интеграции и какие они бывают, рассказала в мини-книге с картинками и примерами.
Файл прикреплен к посту.
Загружайте и погружайтесь в тему глубже 🧩

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

📌 Проект на Интеграцию: приложение курьерской службы #ShipEasyGA 📌

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

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


➡️ Требования

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

Структурирование адреса - это разделение строки на отдельные поля:
✔️ индекс
✔️ страна
✔️ регион / область / др
✔️ город / поселок / др
✔️ улица
✔️ дом
✔️ корпус
✔️ квартира

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

Есть возможность делать доставку “от” и “до” специальных пунктов обслуживания клиентов ShipEasyGA.

✔️ Поэтому для решения задачи потребуются координаты адреса, чтобы предлагать пользователям ближайшие пункты обслуживания в радиусе 10км.


➡️ Сценарии:

1А. Пользователь может ввести адрес в одну строку. В этом случае приложение ShipEasyGA должно автоматически структурировать адрес и предлагать проверить и исправить его, при необходимости.

1B. В мобильном приложении предлагать заполнить адрес отправления по текущим геокоординатам пользователя, автоматически.

2. После ввода адреса предлагать выбрать ближайший пункт обслуживания клиентов, по желанию.

Для структурирования адреса и работы с координатами использовать сервисы DaData.


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


Буду последовательно разбирать решение задач в канале весь сентябрь: исследование и тестирование API, интеграционный Use Case, UML, анализ БД и маппинг данных 🍁

Читайте канал в будние дни, чтобы последовательно изучать тему Интеграций на примере реальной и часто встречающейся задачи 😉

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

📚 Нужно получить или структурировать знания, чтобы перейти в Системный Анализ. С чего начать? 📚

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

Раз в год я запускаю поток по программе:
🚀 Системный аналитик: с нуля до опыта работы на проекте
🗓 Занятия в онлайн начнутся с 26 сентября

Программа актуальна для:
▫️ Технических писателей,
▫️ Тестировщиков,
▫️ Бизнес-аналитиков,
▫️ Младших системных аналитиков,
▫️ Выпускников технических ВУЗов,
которые хотят стать системными аналитиками.

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


👉 А если вы еще изучаете профессию и пытаетесь понять “А надо ли оно мне?”, то предлагаю познакомиться со следующей подборкой материалов:

(П) Как стать системным аналитиком: личный опыт

(C) Процесс работы системного аналитика: практическое руководство, примеры и шаблоны

(C) Карта навыков системного аналитика: как начать карьеру и куда расти

(П) Где искать стажировку на Системного аналитика и как она проходит: реальный опыт

(П) Без ментора на работе: стратегии работы с незнакомыми задачами для Системного Аналитика

(С) Гайд по поиску первой работы

(C) - Статья
(П) - Подкаст


Смена профессии - важный и ответственный шаг. Не стоит делать это бездумно 🙏

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

И если вы многократно обдумали эти пункты, то можно делать новые шаги к большим изменениям 🙌

🌊 Backend и Frontend 🏝

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

🏝 Frontend – это приложения с кнопками, полями ввода и картинками, с которыми взаимодействует пользователь.

Примеры:
- веб-приложение,
- мобильное приложение.

Это все, что пользователь видит и использует напрямую.

Задачи Frontend:
- делать запросы к Backend по API,
- показывать визуальную часть системы пользователю,
- выполнять простую логику (проверка данных, обработка ошибок).



🌊 Backend – это то, что работает "под капотом" системы, или то, что обеспечивает работу Frontend.

Задачи Backend:
- реализовывать API методы, чтобы обрабатывать запросы Frontend,
- читать/писать данные в БД, ФХ и в другие хранилища,
- интеграции с внешними системами,
- фоновые задачи.

Часть из этого мог бы делать и Frontend, но современные мобильные и веб-приложения стараются делать максимально “тупыми” - чем меньше логики, тем лучше. Никто не хочет писать сложную логику в системе с iOS, Android и Web для каждого приложения отдельно, хотя она одинаковая.

Backend — это «мозг» системы, который обеспечивает корректное выполнение всех процессов, проверяет и хранит все данные.


🔸 Понимание разницы между Backend и Frontend важно при работе с интеграциями.

Например, при подключении внешней системы для приема онлайн-оплаты системный аналитик должен понять:

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


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

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

Встань и сделай 20 приседаний 🏋️‍♂️

Конечно, удаленная работа это круто. Возможность путешествовать по миру, не надо утром стоять в пробке, влетать в закрывающуюся дверь электрички или метро. Можно днем лечь поспать вместо обеда, погладить кота, поплавать в море. У кого что.

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

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


Делюсь лайфкаками, как сделать себя подвижными с нашей неподвижной работой:

🟢 Поставь напоминания о перемещении = 1 раз в 60 мин. Выбирайте цель. Например, пройти 5 кругов по дому.

🟢 Забудь про лифты – выбирай лестницу!

🟢 Обязательная послеобеденная прогулка или прогулка в дальний магазин от дома за каким-то снеком каждый день (я так за протеиновыми батончиками ходила раньше, сейчас за кофе 😄)

🟢 Митинги стоя. Если мне не нужно рисовать или печатать, то хожу с ноутбуком по дому.

🟢 Найди РЕГУЛЯРНЫЙ командный вид активности, который понравится: танцы, плавание, велосипед, волейбол, или что-то еще, что приносит удовольствие. Команда заставляет приходить на тренировки

Я использую все эти способы, а еще 6-7 дней в неделю провожу в зале. День без спорта вызывает расстройства и падение энергии.


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

Кстати... Прямо сейчас можно встать и сделать 20 приседаний 😉


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

👉 Use Case: обычный и технический сценарии работы системы 👉

Use Case - это сценарий использования системы.

Его можно описывать на верхнем уровне, не вдаваясь в технические подробности. То есть просто описать процесс работы пользователя с интерфейсом (UI).

Пример обычного Use Case (интеграций во внешние системы нет):

1. Пользователь через главное меню заходит в просмотр информации о своем профиле и переходит к его настройке.

2. Пользователь может поменять фамилию, имя или дату рождения.

3. Пользователь сохраняет изменения.

4. Перед сохранением система проверяет корректность введенных данных:
- дата рождения в формате ДД.ММ.ГГГГ
- фамилия / имя содержит только русские или английские буквы, а также пробелы, до 128 символов.

5. Если проверки пройдены успешно, система сохраняет результат и пользователь возвращается на экран просмотра информации о профиле.

А можно дополнять Use Case вызовами API-методов, обращениями к таблицам БД. Тогда он становится более техническим и более похожим на результат работы системного аналитика.

Пример более технического Use Case (интеграций во внешние системы нет, только Frontend-Backend):

1. Пользователь через главное меню заходит в просмотр информации о своем профиле и переходит к его настройке.
✅

Данные получают методом GET /api/v1/profile.

✅

Запрос подписан авторизацией пользователя.

2. Пользователь может поменять фамилию, имя или дату рождения.

3. Пользователь сохраняет изменения.

4. Перед сохранением

✅

на UI проверяется

корректность введенных данных:
- дата рождения в формате ДД.ММ.ГГГГ
- фамилия / имя содержит только русские или английские буквы, а также пробелы, до 128 символов.

5. Если проверки пройдены успешно, система выполняет запрос к серверу для сохранения данных:

✅

PUT /api/v1/profile/update

✅

Запрос подписан авторизацией пользователя.

✅

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

✅

7. Если проверки пройдены успешно, то сервер сохраняет результаты в БД, в таблице user и возвращает успешный ответ на UI.

✅

8. Пользователь возвращается на экран просмотра информации о своём профиле.

👉 Если мы работаем с задачами на интеграции, важно показать как взаимодействуют Frontend и Backend, наш сервер и внешние системы по API. Упоминание методов API в таких интеграционных Use Case просто необходимы, чтобы передать полноценную постановку задачи на разработчика.

Но прежде чем описывать интеграционные Use Case, всегда важно понять, как будет вести себя наш UI. И как он вообще будет выглядеть. С этого я начинаю работу с любой задачей, не только на интеграции.

Как будет работать форма заказа курьерской службы #ShipEasyGA, а именно - настройка адреса на ней? Разберемся далее 👇

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

👉 Пример Use Case без технических деталей - начало работы с задачей на интеграцию 👉

В проекте #ShipEasyGA нужно подключить внешнюю систему DaData (т.е. сделать интеграцию), которая будет помогать структурировать “а-бы как” введенные адреса по отдельным полям ввода.

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

Поэтому изначально Use Case для работы с адресами будет выглядеть так:


Пользователи и системы:
+ Пользователь
+ Веб-приложение / iOS / Android


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


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

1. Выбор страны:

1.1. Пользователь должен выбрать страну из справочника.
По умолчанию выбрана “Россия”.

1.2. Для выбора страны пользователь нажимает на поле ввода.
Отображается выпадающий список стран по алфавиту. Россия всегда вверху списка, если не введено ни одной буквы.
В списке одновременно отображаются 5 записей, доступна прокрутка.

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

1.4. После выбора страны из списка значение в поле обновляется.
Если пользователь не выбрал страну из списка и снимает выделение с поля, то оставить в нем введенные буквы, подсветить его “красным” и сделать снизу подсказку “Страна не выбрана”.
Поля ввода адреса блокировать до выбора страны из справочника.


#ИнтеграцииGA
Продолжение 👇

👉 Пример Use Case без технических деталей - начало работы с задачей на интеграцию (часть 2) 👉

2. Пользователь вводит Полный адрес.

2.1. При вводе 10 и более символов отображается выпадающий список с подсказками адреса.
🧩 Подсказки берутся из внешней системы DaData.

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

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

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

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

3. Пользователь проверяет структурированный адрес.

Если необходимо, то он вносит правки в него.
При внесении правок строка с полным адресом должна обновляться при завершении редактирования каждого поля - снятия с него выделения.

Выбор региона/области из справочник: поведение аналогично полю выбора страны.
В выпадающем списке отображаются только регионы страны.

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

4. Пользователь продолжает ввод остальных полей на форме для Отправителя и Получателя.

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

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

Технических деталей с вызовом API-метолов в этом Use Case нет. Хотя он детально описывает работу экрана.

А значит нам еще есть над чем работать, чтобы сделать постановку задачу на интеграцию нашего приложения #ShipEasyGA с DaData для структурирования адресов 🙂


P.S. И конечно можно еще поработать над альтернативными сценариямии обработкой ошибок! Их будет больше! Можно сразу предлагать в комментариях


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

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

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

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

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

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

🎁 До 19 сентября: дополнительное обучение по БД в подарок + самые выгодные условия.

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

🧐 Каким способом делать вызов API DaData? 🧐

В приложении курьерской службы #ShipEasyGA для структурирования адресов должен использоваться внешний сервис DaData. Его надо вызывать по API.


Как делать эти вызовы?

1 (👌) Использовать слой Backend ShipEasyGA, который будет обращаться к API DaData.

2 (👍) Напрямую вызывать API DaData с Frontend-ов.


Голосуем реакцией 👌/👍 под постом. Пишем в комментарии какой вариант выглядит лучше и почему.

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