Привет, коллеги! Продолжаем разбирать интеграционный проект GetDelivery.

▫️Этап 2 проектирования Интеграций. Сбор и анализ требований▫️

✅ Цель интеграции:

Разработать и запустить логистический сервис-агрегатор GetDelivery, предоставляющий пользователям удобный доступ к актуальной информации о стоимости и условиях отправления посылки через различные компании доставки (Деловые Линии, СДЭК, Возовоз).

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


✅ Задачи интеграции:

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

✔️ Реализовать интеграцию с сервисами доставки для получения актуальных условий перевозки и выбора сервиса с наиболее выгодными.
- Деловые Линии,
- СДЭК,
- Возовоз.

✔️ Реализовать интеграцию с сервисами доставки для оформления сервисов заказов через них.

✔️ Уведомлять клиентов об обновлении статусов заказов, оформленных через GetDelivery.

✔️ Формировать для владельца GetDelivery отчетность по полученным выплатам за оплаченные заказы.

✔️ Формировать для владельца GetDelivery аналитику - % пользователей, которые выполнили поиск и оплатили заказ с использованием GetDelivery (= кол-во пользователей оформивших заказы и оплативших их / кол-во выполнявших поиски).


И вот на этом моменте я пошла изучать API-документацию.
Всё ли возможно реализовать технически? И если да, то как?

🤖 Что ждать от ChatGPT 4.0 системным аналитикам? 🤖


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

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

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


🤖 Анализ API - документации и описание маппингов данных для интеграций

ChatGPT 4.0 принимает к анализу ссылки на веб-страницы. Теперь всю интерактивную API-документацию можно отправить к нему на анализ. Для нашего проекта GetDelivery можно смело проводить анализ API Деловых Линий, СДЭКа и Возовоза, т.к. мы получили на вход ссылки на их API.


🤖 Генерация требований к системе

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

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


🤖 Помощь в моделировании процессов

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

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


🤖 Поддержка в написании технической документации

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


Что ещё? 👇

👇 Что еще может ChatGPT 4.0?

🤖Интеграция с другими инструментами

ChatGPT 4.0 может быть интегрирован или использован с различными программными инструментами, включая Postman, Swagger, Confluence и другие.

Он может помогать в написании и проверке спецификаций OpenAPI для API, используя актуальные сведения о лучших практиках и стандартах. А также может писать автотесты на ваш API в Postman.


🤖 Улучшение коммуникаций

Теперь можно зачищать свой текст от сложной терминологии прибегая к помощи Искусственного Интеллекта (ИИ). Раньше приходилось вычитывать и править свои тексты вручную, теперь с этим помогает ChatGPT. Генерация понятных объяснений сложных технических концепций может помочь в коммуникации с не-техническими стейкхолдерами.


🤖 Поддержка в принятии решений
🤖 Обратная связь по работе системы и итеративное улучшение
🤖 Самостоятельное обучение и развитие навыков
🤖 Развитие технического английского
🤖 Голосовой набор текста с зачисткой от “шума” и правками по орфографии


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

Яндекс запустил YandexGPT.

⚡ ИИ - новый инструмент IT-команд, который скоро станет обязательным навыком.


Еще не использовали ChatGPT или не знаете как применять? Пока не понимаете как внедрить его в работу, чтобы использовать эффективно?

На воркшопе передам справочник команд. Покажу ChatGPT и YandexGPT!

🤖 Лайфхаки ChatGPT для аналитиков на практике
⚡ 28 Ноября, ВТ | 19:00 (МСК)
🟢 ЗАПИСАТЬСЯ
Разработка требований. Проектирование БД. Создание UML, ER и BPMN диаграмм. Описание интеграционных сценариев. Шаблоны команд и шаблоны проектной документации.


Это тот самый знак, чтобы не откладывать на потом знакомство с ИИ и его самыми актуальными обновлениями 😎

😱 Требования не реализуемы. Тревога. Или? 😱

Я определила бизнес-цели и задачи GetDelivery. Но теперь надо разобраться с их реализуемостью. Это один из главных подвохов в работе с задачами на интеграцию.

Если кто-то сталкивался при разработке требований с термином “Бизнес-правила и ограничения”, то вот они в натуральном виде, только не про бизнес, а технические.

Я ознакомилась с API-документацией и сделала важные заметки для проекта.

✔️ Мы можем оформить заказ, но оплату доставки каждый сервис реализует по-разному.
✔️ Технически мы не имеем возможности менять статус оплаты заказа на доставку груза самостоятельно.

А значит подключить свою платежную систему типа ЮКасса, РайфПэй или подобное мы не можем. Давайте разбираться с тем, что есть.


В деталях:


🔹 Деловые Линии

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

Как я увидела из первичного знакомства - в методах API явно нигде не отображается комиссия. А значит получение комиссии за каждый заказ будет регулироваться договором сотрудничества с Деловыми Линиями. Что это для нас значит? Нужно будет сделать админку, через которую владелец GetDelivery сможет смотреть отчетность и в которой нужно будет запрограммировать правила выплат для нас от Деловых Линий.



Продолжение завтра👇

🔹 СДЭК 👇

Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.

Поэтому тут, прежде чем реализовывать интеграцию, я предлагаю пообщаться с отделом по партнерам СДЭК и уточнить у них условия вознаграждений за то, что мы привлекаем к ним клиентам. И как вообще платежи будут проводиться и учитываться?

Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺

Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...

🔹 Возовоз

Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.

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

Итог этапа анализа и сбора требований 🧐

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

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

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


P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.


P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.

Чтобы перейти к разработке схемы архитектуры GetDelivery, я должна сформулировать бизнес-требования, функциональные и нефункциональные требования?

Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.

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

Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:


Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery

Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).

Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.

Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.

Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.


Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.


Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.


Основной сценарий скоро появится 👀
🔽🔽🔽

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

1. Пользователь вводит данные для расчета стоимости доставки в веб-приложении GetDelivery и инициирует расчет стоимости доставки.

2. Система GetDelivery отправляет запросы к API Деловых Линий, СДЭК, Возовоз для расчета актуальной стоимости доставки.

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

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

5. Пользователь может выбрать предпочтительный вариант в списке предложений, посмотреть его подробности и перейти к оформлению заказа в соответствующем сервисе доставки (Деловые Линии, СДЭК или Возовоз).

—--------

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

1А. Некорректные входные данные:
Если пользователь вводит некорректные или неполные данные, система запрашивает уточнение или коррекцию данных.

2А. Отсутствие ответа от API внешней системы:
Если один из сервисов не отвечает, система сообщает об этом пользователю и предоставляет данные от доступных сервисов.

2B. Ошибка авторизации в API внешней системы:
Необходимо повторить попытку, если она неуспешна, то…. . Это уже технические детали пошли. И они важны! Но позже 🙂



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

Можно переходить к разработке верхнеуровневой схемы архитектуры! 🛠❤️

📋 О важности планирования

Новый год скоро. Планируете что-то?

С тех пор как я начала работать в IT, я всегда планировала, как проведу Новый год. Работа системным аналитиком много принесла в мою жизнь, в частности: системность и путешествия.

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

И далее каждый год, даже во времена пандемии, мне удавалось это сделать. Ранняя покупка билетов на самолет, бронирование отелей, план посещения красивых мест и встречи 00:00 – все это было частью моих последних Новых годов.

И вот что поняла в прошлом году:
Если плана на Новогоднюю ночь нет, то ничего не происходит 😂
Удивительно? Нет.

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

И вот, в этом году Новый год уже спланирован! Ура! Интересно, как все пройдет! Это будет интересное путешествие, несколько городов, и начнётся оно уже совсем скоро. Кажется, что каждый день расписан, каждый день есть планы, даже запасные. Я чувствую спокойствие и уверенность. Всё будет вау!

Наши цели – это наши желания. Хотите получать желаемое? Формулируйте цели четко и стройте планы. Системный анализ помогает 🙂Мечтайте и действуйте! Зима и Новый год – отличный повод начать ❤️

🛠 Use Case для Интеграций: в чем отличия от обычных задач? 🛠 Пока не ушли дальше, хочется напомнить.

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


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


Use Case (или сценарий использования) описывает, КАК эти функциональные требования реализуются, какой последовательностью шагов в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий поиска наиболее выгодного варианта перевозки груза “Проверка Стоимости Доставки в Сервисе GetDelivery” с обращением во внешние системы Деловые Линии, СДЭК и Возовоз.


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


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

В сценарии интеграций всегда есть минимум два участника. А вообще больше:


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

В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.

Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).


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

В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.

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

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


🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.


🔹Пользователи, которые запускают интеграционные процессы в системе.

🔺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.

🗼 Поговорим про архитектуру 🗽

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

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


Различают основные подходы к проектированию архитектуры:

🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.

🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.

🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.

🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.

🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.


Я хочу познакомить вас с монолитами, SOA и MSA.

Начнем с 🗽Монолитной архитектуры!

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

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

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


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



➕ Плюсы:

+ Удобно для небольших приложений.

+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.

+ Просто для поддержки - всё в одном месте.


➖ Минусы:

- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.

- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.

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

- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.



Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.

🗽 Монолитная архитектура

Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:

🔺 Одна общая БД (хотя можно и несколько).

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

🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.

🔺 У монолита может быть свой API для мобильных приложений.


Представим GetDelivery как монолит - бюджетный вариант реализации 😄

Буквально вчера я встретила знакомую в спортзале и на моё “Как дела?” она сказала:

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

И так мне оказалась знакома эта история. Моя история.

“Мне не нравится сидеть на месте. Я устала от однообразия. Хочется что-то новое, лучшее. Я пока не знаю как и что, но всё будет по-другому. Рутина и однообразие - не моё, мне скучно!”

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

Было страшно, было непонятно. И вот сейчас всё по-другому. Капитально. Новые проекты и работа, где я сама у себя в найме, проекты, несколько команд, половина жизни на английском, который когда-то был для меня невозможным, новые люди, город, страна, другая сторона планеты. Изменения сейчас идут постоянно!

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

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

Я искренне благодарна ученикам GetAnalyst за обратную связь. После CustDev я всегда вижу их успешные истории, происходящие в процессе обучения. А это значит, что одно из моих желаний за последние годы исполнилось:

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

Продолжаем работать. Всё получится! ❤️

🗽 Сервисная архитектура, или SOA (Service-Oriented Architecture), это подход к разработке программного обеспечения, при котором приложение состоит из нескольких сервисов, взаимодействующих друг с другом.

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

Сервисная архитектура (SOA) включает в себя несколько сервисов, которые общаются между собой, обычно используя сетевые протоколы, например HTTP. Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенную функцию, и предоставляет API, через который другие сервисы могут запрашивать данные или вызывать его функции. Это как язык, на котором сервисы "разговаривают" друг с другом.

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

Одно из основных отличий от микросервисной архитектуры - несколько сервисов могут взаимодействовать с одной базой данных.


➕ Плюсы:

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

+ Изменения в одном сервисе редко влияют на другие при хорошей архитектуре.

+ Разработкой могут заниматься независимые друг от друга команды.

+ Одни и те же сервисы могут использоваться в разных частях приложения или даже в разных приложениях (вызываться в ходе выполнения алгоритма работы).

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


➖ Минусы:

- Сложность управления: требует тщательного планирования и координации между сервисами, нужна опытная команда.

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

- Трудности в отладке: отслеживание ошибок может быть сложнее из-за распределенной природы системы.

Ну мы или не мы? 😀

Всем огромного заряда энергии в этот первый понедельник декабря! ❄️⛄️
Продолжаем работать с архитектурой и нашим сервисом GetDelivery.


🗽 Микросервисная архитектура (MSA) - это разновидность сервисной архитектуры (SOA).

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

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

Каждый микросервис имеет свою независимую БД.


➕ Плюсы:

+ Легче добавлять и обновлять функциональность.

+ Ошибки в одном микросервисе менее вероятно повлияют на всю систему.

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

+ Каждый микросервис может использовать ту технологию, которая наиболее подходит для его задач: один микросервис с в системе использует СУБД postgreSQL, второй SQLite; один с REST API, а второй с graphQL.


➖ Минусы:

- Большее количество компонентов требует более сложного управления и мониторинга.

- Общение между микросервисами через сеть может приводить к сетевым задержкам.

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

- Тестирование становится более сложным из-за распределенной природы системы.

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

Что на схеме архитектуры? 🤔


1. Клиенты

Как и в монолите, список клиентов сохраняется. Единственное, я добавила в этот список панель администратора системы (Web App Admin), чтобы дальше рассказать про отдельные сервисы.


3. Внешние системы

Перечень внешних систем, с которыми необходимо реализовать интеграцию.
Хочу отметить, что на схеме важно показать виды API по которым будет проходить интеграция: REST API, GraphQL, SOAP API, ftp или другие. Пока я этого не сделала, но нужно будет добавить.

Также хочу обратить ваше внимание, что внешняя система - это черный ящик. На схеме архитектуры нашей системы не надо рисовать их БД, если мы о ней ничего не знаем. Мы пользуемся API для интеграций систем доставки с GetDelivery, чтобы не думать об их БД. Ведь именно с целью скрыть прямой доступ к БД СДЭК, Возовоз и Деловые Линии делали публичные API.



2. Backend - серверное приложение с сервисной архитектурой (SOA)

Рассказываю про компоненты и почему они выделены:

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

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

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


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

Продолжение - переход от монолита к SOA 👇


2. Backend - серверное приложение с сервисной архитектурой (SOA)

Рассказываю про компоненты и почему они выделены:

🔺 Сервис основной логики -
основные функции системы, которые не относятся к остальным сервисам системы. Это подобие монолита внутри сервисной архитектуры и именно так система может выглядеть в промежуточном состоянии при переходе от монолитной архитектуры к SOA или MSA.

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

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

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

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


🔺 Сервис генерации отчетов -
предназначен для сбора данных и генерации PDF-файлов на их основе по запросам от приложения администратора. Выделение этого сервиса оправдано тем, что генерация файлов и запись их в файловое хранилище может занять длительное время и лучше это делать на отдельном сервере, выделять под это отдельные мощности.


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

Если сравнить исходную схему монолита GetDelivery с полученной картинкой SOA, то можно увидеть наглядно как можно последовательно выделять сервисы от основного бэкенда в отдельные сервисы. Еще раз напомню - на картинке “Сервис основной логики” это монолит, из которого можно выделить еще больше сервисов и микросервисов, когда до конца разберемся с бизнес-процессами и функциональностью системы.