🔹 СДЭК 👇
Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.
Поэтому тут, прежде чем реализовывать интеграцию, я предлагаю пообщаться с отделом по партнерам СДЭК и уточнить у них условия вознаграждений за то, что мы привлекаем к ним клиентам. И как вообще платежи будут проводиться и учитываться?
Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺
Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...
🔹 Возовоз
Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.
Партнерские комиссии опять же могут регулироваться только бизнес-договором. И нужно сообщить заказчику о том, что информация по всем взаиморасчетам и учетам прибыли может быть только на нашей стороне. История повторяется.
Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.
Поэтому тут, прежде чем реализовывать интеграцию, я предлагаю пообщаться с отделом по партнерам СДЭК и уточнить у них условия вознаграждений за то, что мы привлекаем к ним клиентам. И как вообще платежи будут проводиться и учитываться?
Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺
Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...
🔹 Возовоз
Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.
Партнерские комиссии опять же могут регулироваться только бизнес-договором. И нужно сообщить заказчику о том, что информация по всем взаиморасчетам и учетам прибыли может быть только на нашей стороне. История повторяется.
👍5❤2🥰1
Итог этапа анализа и сбора требований 🧐
Пока есть вопросы в части оплаты заказов и получения комиссий. Придется приложить больше усилий на этапе детального проектирования и по возможности заранее пообщаться с разработчиками внешних систем. Калькулятор стоимости доставки предоставляется во всех API.
Я, как системный аналитик, подготовлю отчет для заказчика с НЕтехническими вопросами, а лучше проведу очную встречу и расскажу об особенностях, с которыми я встретилась при техническом анализе.
Основные вопросы у меня бизнесовые - по соглашениям о комиссиях и ответственности за реальные деньги пользователей. Но эти вопросы возникли только после технического анализа.
P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.
P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.
Пока есть вопросы в части оплаты заказов и получения комиссий. Придется приложить больше усилий на этапе детального проектирования и по возможности заранее пообщаться с разработчиками внешних систем. Калькулятор стоимости доставки предоставляется во всех API.
Я, как системный аналитик, подготовлю отчет для заказчика с НЕтехническими вопросами, а лучше проведу очную встречу и расскажу об особенностях, с которыми я встретилась при техническом анализе.
Основные вопросы у меня бизнесовые - по соглашениям о комиссиях и ответственности за реальные деньги пользователей. Но эти вопросы возникли только после технического анализа.
P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.
P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.
👍6🔥2
Чтобы перейти к разработке схемы архитектуры GetDelivery, я должна сформулировать бизнес-требования, функциональные и нефункциональные требования?
Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.
Для примера беру сценарий расчета стоимости доставки. Описывать его буду на бизнес-уровне, без технических деталей, но с упоминанием всех внешних систем, с которыми предстоит интеграция. Часть с созданием заказов и уведомлениями не рассматриваю до открытого вебинара (это намек).
Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:
Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery
Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).
Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.
Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.
Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.
Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.
Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.
Основной сценарий скоро появится 👀
🔽🔽🔽
Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.
Для примера беру сценарий расчета стоимости доставки. Описывать его буду на бизнес-уровне, без технических деталей, но с упоминанием всех внешних систем, с которыми предстоит интеграция. Часть с созданием заказов и уведомлениями не рассматриваю до открытого вебинара (это намек).
Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:
Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery
Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).
Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.
Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.
Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.
Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.
Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.
Основной сценарий скоро появится 👀
🔽🔽🔽
👍8❤4👀3👎1
Основной Сценарий:
1. Пользователь вводит данные для расчета стоимости доставки в веб-приложении GetDelivery и инициирует расчет стоимости доставки.
2. Система GetDelivery отправляет запросы к API Деловых Линий, СДЭК, Возовоз для расчета актуальной стоимости доставки.
3. Полученные данные собираются и обрабатываются в GetDelivery.
Выполняется сравнение условий для выбора наиболее выгодного предложения, которое отобразится для пользователя.
4. Пользователю в веб-приложении отображается список результатов расчета стоимости перевозки груза на разных условиях и на разных тарифах - список предложений.
5. Пользователь может выбрать предпочтительный вариант в списке предложений, посмотреть его подробности и перейти к оформлению заказа в соответствующем сервисе доставки (Деловые Линии, СДЭК или Возовоз).
—--------
Альтернативные сценарии и обработка ошибок:
** Это раздел на котором стоит сфокусироваться в процессе работы с интеграционными задачами.
1А. Некорректные входные данные:
Если пользователь вводит некорректные или неполные данные, система запрашивает уточнение или коррекцию данных.
2А. Отсутствие ответа от API внешней системы:
Если один из сервисов не отвечает, система сообщает об этом пользователю и предоставляет данные от доступных сервисов.
2B. Ошибка авторизации в API внешней системы:
Необходимо повторить попытку, если она неуспешна, то…. . Это уже технические детали пошли. И они важны! Но позже 🙂
Основной сценарий работы системы описан. Про оформление доставки тоже примерно понимаем как это должно работать, и, если что, будем уточнять в процессе проектирования.
Можно переходить к разработке верхнеуровневой схемы архитектуры! 🛠❤️
1. Пользователь вводит данные для расчета стоимости доставки в веб-приложении GetDelivery и инициирует расчет стоимости доставки.
2. Система GetDelivery отправляет запросы к API Деловых Линий, СДЭК, Возовоз для расчета актуальной стоимости доставки.
3. Полученные данные собираются и обрабатываются в GetDelivery.
Выполняется сравнение условий для выбора наиболее выгодного предложения, которое отобразится для пользователя.
4. Пользователю в веб-приложении отображается список результатов расчета стоимости перевозки груза на разных условиях и на разных тарифах - список предложений.
5. Пользователь может выбрать предпочтительный вариант в списке предложений, посмотреть его подробности и перейти к оформлению заказа в соответствующем сервисе доставки (Деловые Линии, СДЭК или Возовоз).
—--------
Альтернативные сценарии и обработка ошибок:
** Это раздел на котором стоит сфокусироваться в процессе работы с интеграционными задачами.
1А. Некорректные входные данные:
Если пользователь вводит некорректные или неполные данные, система запрашивает уточнение или коррекцию данных.
2А. Отсутствие ответа от API внешней системы:
Если один из сервисов не отвечает, система сообщает об этом пользователю и предоставляет данные от доступных сервисов.
2B. Ошибка авторизации в API внешней системы:
Необходимо повторить попытку, если она неуспешна, то…. . Это уже технические детали пошли. И они важны! Но позже 🙂
Основной сценарий работы системы описан. Про оформление доставки тоже примерно понимаем как это должно работать, и, если что, будем уточнять в процессе проектирования.
Можно переходить к разработке верхнеуровневой схемы архитектуры! 🛠❤️
👍7❤1👎1
📋 О важности планирования
Новый год скоро. Планируете что-то?
С тех пор как я начала работать в IT, я всегда планировала, как проведу Новый год. Работа системным аналитиком много принесла в мою жизнь, в частности: системность и путешествия.
С началом работы в IT я начала много путешествовать и исполнять свое детское желание - смотреть на мир. Вспоминаю один из первых годов, когда дала себе обещание: всегда встречать Новый год за границей, и желательно в теплых краях.
И далее каждый год, даже во времена пандемии, мне удавалось это сделать. Ранняя покупка билетов на самолет, бронирование отелей, план посещения красивых мест и встречи 00:00 – все это было частью моих последних Новых годов.
И вот что поняла в прошлом году:
Если плана на Новогоднюю ночь нет, то ничего не происходит 😂
Удивительно? Нет.
В прошлом году плана не было. Я до последнего не знала, как буду праздновать. И в итоге Новый год прошел дома, организованный в последний момент. Ну хоть в теплых краях, с прогулкой у океана. Так случилось из-за большого количества переживаний и перемен, я посвятила ту Новогоднюю ночь осознанию что произошло за один год.
И вот, в этом году Новый год уже спланирован! Ура! Интересно, как все пройдет! Это будет интересное путешествие, несколько городов, и начнётся оно уже совсем скоро. Кажется, что каждый день расписан, каждый день есть планы, даже запасные. Я чувствую спокойствие и уверенность. Всё будет вау!
Наши цели – это наши желания. Хотите получать желаемое? Формулируйте цели четко и стройте планы. Системный анализ помогает 🙂Мечтайте и действуйте! Зима и Новый год – отличный повод начать ❤️
Новый год скоро. Планируете что-то?
С тех пор как я начала работать в IT, я всегда планировала, как проведу Новый год. Работа системным аналитиком много принесла в мою жизнь, в частности: системность и путешествия.
С началом работы в IT я начала много путешествовать и исполнять свое детское желание - смотреть на мир. Вспоминаю один из первых годов, когда дала себе обещание: всегда встречать Новый год за границей, и желательно в теплых краях.
И далее каждый год, даже во времена пандемии, мне удавалось это сделать. Ранняя покупка билетов на самолет, бронирование отелей, план посещения красивых мест и встречи 00:00 – все это было частью моих последних Новых годов.
И вот что поняла в прошлом году:
Если плана на Новогоднюю ночь нет, то ничего не происходит 😂
Удивительно? Нет.
В прошлом году плана не было. Я до последнего не знала, как буду праздновать. И в итоге Новый год прошел дома, организованный в последний момент. Ну хоть в теплых краях, с прогулкой у океана. Так случилось из-за большого количества переживаний и перемен, я посвятила ту Новогоднюю ночь осознанию что произошло за один год.
И вот, в этом году Новый год уже спланирован! Ура! Интересно, как все пройдет! Это будет интересное путешествие, несколько городов, и начнётся оно уже совсем скоро. Кажется, что каждый день расписан, каждый день есть планы, даже запасные. Я чувствую спокойствие и уверенность. Всё будет вау!
Наши цели – это наши желания. Хотите получать желаемое? Формулируйте цели четко и стройте планы. Системный анализ помогает 🙂Мечтайте и действуйте! Зима и Новый год – отличный повод начать ❤️
🔥15❤8👍6👎2
🛠 Use Case для Интеграций: в чем отличия от обычных задач? 🛠 Пока не ушли дальше, хочется напомнить.
Когда мы говорим об интеграциях, то основное отличие для аналитиков от обычных задач начинается при разработке функциональных требований, когда мы описываем сценарии работы пользователей и функциональные возможности системы.
Функциональные требования определяют, ЧТО система должна делать.
Это описания возможностей или характеристик системы, которые влияют на ее поведение.
Пример: "Система должна предоставлять возможность пользователям задавать адреса отправления и получения груза с использованием справочника адресов".
Use Case (или сценарий использования) описывает, КАК эти функциональные требования реализуются, какой последовательностью шагов в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий поиска наиболее выгодного варианта перевозки груза “Проверка Стоимости Доставки в Сервисе GetDelivery” с обращением во внешние системы Деловые Линии, СДЭК и Возовоз.
Что такое интеграционный Use Case?
В контексте интеграционных Use Cases рассматриваются ситуации, когда наша система взаимодействует не только с пользователями, но и с другими системами.
Например, в сценарии, где пользователь оформляет заказ в онлайн-сервисе доставки, этот заказ может передаваться в систему управления заказами для обработки или в финансовую систему для ведения учета.
В заключении:
Use Case описывает поведение системы:
🔸 в ответ на действия конкретного пользователя - обычные Use Cases,
🔸 при взаимодействии с внешней системой - интеграционные Use Cases.
Когда мы говорим об интеграциях, то основное отличие для аналитиков от обычных задач начинается при разработке функциональных требований, когда мы описываем сценарии работы пользователей и функциональные возможности системы.
Функциональные требования определяют, ЧТО система должна делать.
Это описания возможностей или характеристик системы, которые влияют на ее поведение.
Пример: "Система должна предоставлять возможность пользователям задавать адреса отправления и получения груза с использованием справочника адресов".
Use Case (или сценарий использования) описывает, КАК эти функциональные требования реализуются, какой последовательностью шагов в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий поиска наиболее выгодного варианта перевозки груза “Проверка Стоимости Доставки в Сервисе GetDelivery” с обращением во внешние системы Деловые Линии, СДЭК и Возовоз.
Что такое интеграционный Use Case?
В контексте интеграционных Use Cases рассматриваются ситуации, когда наша система взаимодействует не только с пользователями, но и с другими системами.
Например, в сценарии, где пользователь оформляет заказ в онлайн-сервисе доставки, этот заказ может передаваться в систему управления заказами для обработки или в финансовую систему для ведения учета.
В заключении:
Use Case описывает поведение системы:
🔸 в ответ на действия конкретного пользователя - обычные Use Cases,
🔸 при взаимодействии с внешней системой - интеграционные Use Cases.
👍5🔥3👎1
В сценарии интеграций всегда есть минимум два участника. А вообще больше:
🔹Наша система (Backend) - которая отвечает за работу сценария Use Case, реализует его логику. Основная часть интеграций в проектах обычно реализуется на бэкенде.
В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.
Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).
🔹Внешняя система - с которой мы интегрируемся, к которой делаем запросы. Важно понимать, что внешние системы в процессе интеграции могут быть как внутри одного проекта, так и за пределами - разработаны другими разработчиками, в других компаниях.
В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.
А можно сделать распределенную архитектуру проекта и сказать, что наш сервис управления данными о пользователях будет взаимодействовать с нашим же интеграционным сервисом для расчета стоимости доставки.
Это взаимодействие = внутренняя Интеграция.
Т.к. например, сервис пользователей - основной в интеграционном Use Case для получения истории запросов пользователя, а сервис расчета стоимости может быть внешней системой по отношению к нему. Зависит от контекста.
🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.
🔹Пользователи, которые запускают интеграционные процессы в системе.
🔹Наша система (Backend) - которая отвечает за работу сценария Use Case, реализует его логику. Основная часть интеграций в проектах обычно реализуется на бэкенде.
В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.
Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).
🔹Внешняя система - с которой мы интегрируемся, к которой делаем запросы. Важно понимать, что внешние системы в процессе интеграции могут быть как внутри одного проекта, так и за пределами - разработаны другими разработчиками, в других компаниях.
В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.
А можно сделать распределенную архитектуру проекта и сказать, что наш сервис управления данными о пользователях будет взаимодействовать с нашим же интеграционным сервисом для расчета стоимости доставки.
Это взаимодействие = внутренняя Интеграция.
Т.к. например, сервис пользователей - основной в интеграционном Use Case для получения истории запросов пользователя, а сервис расчета стоимости может быть внешней системой по отношению к нему. Зависит от контекста.
🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.
🔹Пользователи, которые запускают интеграционные процессы в системе.
❤6👍3
🔺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.
-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.
ℹ️ Роли пользователей:
Здесь могут отсутствовать пользователи, т.к. сценарий может запускаться автоматически, например, по расписанию. Но и в обычных сценариях это тоже допустимо.
ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.
ℹ️ Входные данные:
Здесь может быть ситуация, когда входные данные надо получать из внешней системы и сценарий начинается с обращения к ней. В это случае лучше текстом прописать какие данные и откуда получить.
ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.
ℹ️ Основной сценарий:
1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.
3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.
4. Внешние системы могут иметь свои ограничения. Например, если их API предоставляет меньше данных, чем нам нужно, это может стать проблемой. Наоборот, если внешняя система предоставляет слишком много информации, нам придется отбирать только необходимую.
Для этого системные аналитики описывают маппинги данных к Use Case.
ℹ️ Обработка ошибок и альтернативные сценарии:
1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.
1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.
2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.
...
-----------------------
Умение видеть и выделять интеграционные Use Cases помогает заранее поставить себе в планы на аналитику четкий объем задач, избежать проблем с оценкой времени и проблем реализации разработчиками (куча вопросов после передачи требований).
Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.
👍15👏2👎1
🗼 Поговорим про архитектуру 🗽
Архитектура информационных систем — это как чертежи для строительства дома. Она описывает, как разные части программы связаны между собой и как они работают вместе.
Архитектор зданий планирует размеры комнат и их расположение, количество этажей в доме, и соответствующий размер фундамента под него. Архитектор в IT определяет, где хранятся данные, где и как они обрабатываются, как различные части системы будут взаимодействовать друг с другом.
Различают основные подходы к проектированию архитектуры:
🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.
🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.
🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.
🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.
🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.
Я хочу познакомить вас с монолитами, SOA и MSA.
Архитектура информационных систем — это как чертежи для строительства дома. Она описывает, как разные части программы связаны между собой и как они работают вместе.
Архитектор зданий планирует размеры комнат и их расположение, количество этажей в доме, и соответствующий размер фундамента под него. Архитектор в IT определяет, где хранятся данные, где и как они обрабатываются, как различные части системы будут взаимодействовать друг с другом.
Различают основные подходы к проектированию архитектуры:
🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.
🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.
🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.
🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.
🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.
Я хочу познакомить вас с монолитами, SOA и MSA.
🔥21❤3👍2
Начнем с 🗽Монолитной архитектуры!
Монолитную архитектуру систем можно сравнить с одним большим зданием, где все комнаты (функции) находятся под одной крышей. Всё в одном пространстве без разделения на отдельные комнаты.
В такой архитектуре вся программа — это один большой блок, где все части тесно связаны и работают вместе. И если течет крыша и надо сделать ремонт, то будут задеты все помещения.
Монолитный подход к архитектуре был очень популярен на ранних этапах развития программирования, потому что он прост в создании и управлении. Он упрощает проект на старте разработки. Монолитные системы дешевые в разработке и запуске. До сих пор очень часто стартапы начинаются именно с монолитной архитектуры.
👆Важно помнить, если нужно что-то изменить в монолите, приходится работать со всей системой целиком. После доработки маленькой функции придётся обновлять всё приложение. Это приводит к “регламентным окнам” во время обновления, т.к. всё приложение перезапускается и становится временно недоступно пользователям.
➕ Плюсы:
+ Удобно для небольших приложений.
+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.
+ Просто для поддержки - всё в одном месте.
➖ Минусы:
- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.
- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.
- Все части сильно связаны друг с другом. При обновлении одной функции легко можно сломать несколько связанных. Систему тяжело развивать.
- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.
Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.
Монолитную архитектуру систем можно сравнить с одним большим зданием, где все комнаты (функции) находятся под одной крышей. Всё в одном пространстве без разделения на отдельные комнаты.
В такой архитектуре вся программа — это один большой блок, где все части тесно связаны и работают вместе. И если течет крыша и надо сделать ремонт, то будут задеты все помещения.
Монолитный подход к архитектуре был очень популярен на ранних этапах развития программирования, потому что он прост в создании и управлении. Он упрощает проект на старте разработки. Монолитные системы дешевые в разработке и запуске. До сих пор очень часто стартапы начинаются именно с монолитной архитектуры.
👆Важно помнить, если нужно что-то изменить в монолите, приходится работать со всей системой целиком. После доработки маленькой функции придётся обновлять всё приложение. Это приводит к “регламентным окнам” во время обновления, т.к. всё приложение перезапускается и становится временно недоступно пользователям.
➕ Плюсы:
+ Удобно для небольших приложений.
+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.
+ Просто для поддержки - всё в одном месте.
➖ Минусы:
- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.
- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.
- Все части сильно связаны друг с другом. При обновлении одной функции легко можно сломать несколько связанных. Систему тяжело развивать.
- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.
Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.
👍15
🗽 Монолитная архитектура
Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:
🔺 Одна общая БД (хотя можно и несколько).
🔺 Вся логика, касающаяся регистрации и авторизации пользователей, расчета стоимости, платежей за заказы доставки или другие услуги будет в одном месте - на одном сервере. Если дорабатываем функцию создания заказа на доставку, то придется обновлять всё приложение.
🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.
🔺 У монолита может быть свой API для мобильных приложений.
Представим GetDelivery как монолит - бюджетный вариант реализации 😄
Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:
🔺 Одна общая БД (хотя можно и несколько).
🔺 Вся логика, касающаяся регистрации и авторизации пользователей, расчета стоимости, платежей за заказы доставки или другие услуги будет в одном месте - на одном сервере. Если дорабатываем функцию создания заказа на доставку, то придется обновлять всё приложение.
🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.
🔺 У монолита может быть свой API для мобильных приложений.
Представим GetDelivery как монолит - бюджетный вариант реализации 😄
👍5❤4🔥3
Буквально вчера я встретила знакомую в спортзале и на моё “Как дела?” она сказала:
“Пойдёт. Возможно я перееду из Калифорнии. Пока не знаю куда. Но я точно знаю, что будут изменения. Я чувствую, что по-старому мне уже не нравится и знаю, что хочу и сделаю свою жизнь другой. Но пока не знаю как это будет. Чувствую, что это переходный период.”
И так мне оказалась знакома эта история. Моя история.
“Мне не нравится сидеть на месте. Я устала от однообразия. Хочется что-то новое, лучшее. Я пока не знаю как и что, но всё будет по-другому. Рутина и однообразие - не моё, мне скучно!”
В последний раз я сказала себе это летом 2021 года, будучи в Сочи, когда случилось несколько стрессовых ситуаций, которые были даны мне с целью подсветить: ты можешь больше, не сиди на месте - это не про тебя! И тогда я вошла в такой же переходный период. Я понимала, что по-старому уже не работает, а что будет новое - не ясно.
Было страшно, было непонятно. И вот сейчас всё по-другому. Капитально. Новые проекты и работа, где я сама у себя в найме, проекты, несколько команд, половина жизни на английском, который когда-то был для меня невозможным, новые люди, город, страна, другая сторона планеты. Изменения сейчас идут постоянно!
Сбылось много всего, что я просто когда-то вписывала в мечты на 40+ или представляла себе как нереалистичное, но желанное. И всё получилось как есть сейчас. Череда событий всё сделала, а я работала над тем, чтобы из любых ситуаций забирать уроки и пользу. И просто много работала.
В жизни бывает, что ты хочешь что-то менять. Иногда для ускорения нужна помощь других людей, или ситуации. У всех по-разному. Но результат один. Если хочется лучше, то это возможно.
Я искренне благодарна ученикам GetAnalyst за обратную связь. После CustDev я всегда вижу их успешные истории, происходящие в процессе обучения. А это значит, что одно из моих желаний за последние годы исполнилось:
Помогать людям открывать новые возможности, чтобы они могли исполнять свои желания.
Продолжаем работать. Всё получится! ❤️
“Пойдёт. Возможно я перееду из Калифорнии. Пока не знаю куда. Но я точно знаю, что будут изменения. Я чувствую, что по-старому мне уже не нравится и знаю, что хочу и сделаю свою жизнь другой. Но пока не знаю как это будет. Чувствую, что это переходный период.”
И так мне оказалась знакома эта история. Моя история.
“Мне не нравится сидеть на месте. Я устала от однообразия. Хочется что-то новое, лучшее. Я пока не знаю как и что, но всё будет по-другому. Рутина и однообразие - не моё, мне скучно!”
В последний раз я сказала себе это летом 2021 года, будучи в Сочи, когда случилось несколько стрессовых ситуаций, которые были даны мне с целью подсветить: ты можешь больше, не сиди на месте - это не про тебя! И тогда я вошла в такой же переходный период. Я понимала, что по-старому уже не работает, а что будет новое - не ясно.
Было страшно, было непонятно. И вот сейчас всё по-другому. Капитально. Новые проекты и работа, где я сама у себя в найме, проекты, несколько команд, половина жизни на английском, который когда-то был для меня невозможным, новые люди, город, страна, другая сторона планеты. Изменения сейчас идут постоянно!
Сбылось много всего, что я просто когда-то вписывала в мечты на 40+ или представляла себе как нереалистичное, но желанное. И всё получилось как есть сейчас. Череда событий всё сделала, а я работала над тем, чтобы из любых ситуаций забирать уроки и пользу. И просто много работала.
В жизни бывает, что ты хочешь что-то менять. Иногда для ускорения нужна помощь других людей, или ситуации. У всех по-разному. Но результат один. Если хочется лучше, то это возможно.
Я искренне благодарна ученикам GetAnalyst за обратную связь. После CustDev я всегда вижу их успешные истории, происходящие в процессе обучения. А это значит, что одно из моих желаний за последние годы исполнилось:
Помогать людям открывать новые возможности, чтобы они могли исполнять свои желания.
Продолжаем работать. Всё получится! ❤️
❤37👍7
🗽 Сервисная архитектура, или SOA (Service-Oriented Architecture), это подход к разработке программного обеспечения, при котором приложение состоит из нескольких сервисов, взаимодействующих друг с другом.
Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенные функции.
Сервисная архитектура (SOA) включает в себя несколько сервисов, которые общаются между собой, обычно используя сетевые протоколы, например HTTP. Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенную функцию, и предоставляет API, через который другие сервисы могут запрашивать данные или вызывать его функции. Это как язык, на котором сервисы "разговаривают" друг с другом.
Обновление (или релиз) в сервисной архитектуре часто происходит на уровне отдельных сервисов, что позволяет минимизировать риск и упростить процесс внедрения новых функций или исправлений.
Одно из основных отличий от микросервисной архитектуры - несколько сервисов могут взаимодействовать с одной базой данных.
➕ Плюсы:
+ Можно легко добавлять новые сервисы или обновлять существующие, не трогая при этом всю систему, а внося изменения частично.
+ Изменения в одном сервисе редко влияют на другие при хорошей архитектуре.
+ Разработкой могут заниматься независимые друг от друга команды.
+ Одни и те же сервисы могут использоваться в разных частях приложения или даже в разных приложениях (вызываться в ходе выполнения алгоритма работы).
+ При масштабировании и увеличении числа пользователей, если мы знаем, что основная нагрузка на сервис поиска вариантов перевозки, а не на сервис платежей, то мы увеличиваем ресурсы только на него.
➖ Минусы:
- Сложность управления: требует тщательного планирования и координации между сервисами, нужна опытная команда.
- Проблемы производительности: сетевое взаимодействие между сервисами может замедлять отклик системы.
- Трудности в отладке: отслеживание ошибок может быть сложнее из-за распределенной природы системы.
Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенные функции.
Сервисная архитектура (SOA) включает в себя несколько сервисов, которые общаются между собой, обычно используя сетевые протоколы, например HTTP. Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенную функцию, и предоставляет API, через который другие сервисы могут запрашивать данные или вызывать его функции. Это как язык, на котором сервисы "разговаривают" друг с другом.
Обновление (или релиз) в сервисной архитектуре часто происходит на уровне отдельных сервисов, что позволяет минимизировать риск и упростить процесс внедрения новых функций или исправлений.
Одно из основных отличий от микросервисной архитектуры - несколько сервисов могут взаимодействовать с одной базой данных.
➕ Плюсы:
+ Можно легко добавлять новые сервисы или обновлять существующие, не трогая при этом всю систему, а внося изменения частично.
+ Изменения в одном сервисе редко влияют на другие при хорошей архитектуре.
+ Разработкой могут заниматься независимые друг от друга команды.
+ Одни и те же сервисы могут использоваться в разных частях приложения или даже в разных приложениях (вызываться в ходе выполнения алгоритма работы).
+ При масштабировании и увеличении числа пользователей, если мы знаем, что основная нагрузка на сервис поиска вариантов перевозки, а не на сервис платежей, то мы увеличиваем ресурсы только на него.
➖ Минусы:
- Сложность управления: требует тщательного планирования и координации между сервисами, нужна опытная команда.
- Проблемы производительности: сетевое взаимодействие между сервисами может замедлять отклик системы.
- Трудности в отладке: отслеживание ошибок может быть сложнее из-за распределенной природы системы.
❤13👍5
Всем огромного заряда энергии в этот первый понедельник декабря! ❄️⛄️
Продолжаем работать с архитектурой и нашим сервисом GetDelivery.
🗽 Микросервисная архитектура (MSA) - это разновидность сервисной архитектуры (SOA).
Приложение также состоит из сервисов, но они меньше по размеру и разрабатываются под конкретные узкие задачи, то есть выполняет свои специфические функции. Эти сервисы могут быть разработаны, развернуты и обновлены независимо друг от друга. В SOA при этом сервисы могут быть больше и охватывать более широкий спектр функциональности.
В микросервисной архитектуре сервисы также взаимодействуют друг с другом с использованием простых способов, таких как API (Application Programming Interfaces). API обеспечивают стандартизированный способ передачи данных и запросов между различными сервисами, делая процесс их использования удобным при программировании для разработчиков.
Каждый микросервис имеет свою независимую БД.
➕ Плюсы:
+ Легче добавлять и обновлять функциональность.
+ Ошибки в одном микросервисе менее вероятно повлияют на всю систему.
+ Разные команды могут разрабатывать разные микросервисы параллельно, что ускоряет разработку.
+ Каждый микросервис может использовать ту технологию, которая наиболее подходит для его задач: один микросервис с в системе использует СУБД postgreSQL, второй SQLite; один с REST API, а второй с graphQL.
➖ Минусы:
- Большее количество компонентов требует более сложного управления и мониторинга.
- Общение между микросервисами через сеть может приводить к сетевым задержкам.
- Большее количество точек взаимодействия с системой увеличивает риск несанкционированного доступа. В то же время при хороших настройках безопасности это может оказаться плюсом, что утеряны будут данные только взломанного микросервиса, а не всей системы.
- Тестирование становится более сложным из-за распределенной природы системы.
Продолжаем работать с архитектурой и нашим сервисом GetDelivery.
🗽 Микросервисная архитектура (MSA) - это разновидность сервисной архитектуры (SOA).
Приложение также состоит из сервисов, но они меньше по размеру и разрабатываются под конкретные узкие задачи, то есть выполняет свои специфические функции. Эти сервисы могут быть разработаны, развернуты и обновлены независимо друг от друга. В SOA при этом сервисы могут быть больше и охватывать более широкий спектр функциональности.
В микросервисной архитектуре сервисы также взаимодействуют друг с другом с использованием простых способов, таких как API (Application Programming Interfaces). API обеспечивают стандартизированный способ передачи данных и запросов между различными сервисами, делая процесс их использования удобным при программировании для разработчиков.
Каждый микросервис имеет свою независимую БД.
➕ Плюсы:
+ Легче добавлять и обновлять функциональность.
+ Ошибки в одном микросервисе менее вероятно повлияют на всю систему.
+ Разные команды могут разрабатывать разные микросервисы параллельно, что ускоряет разработку.
+ Каждый микросервис может использовать ту технологию, которая наиболее подходит для его задач: один микросервис с в системе использует СУБД postgreSQL, второй SQLite; один с REST API, а второй с graphQL.
➖ Минусы:
- Большее количество компонентов требует более сложного управления и мониторинга.
- Общение между микросервисами через сеть может приводить к сетевым задержкам.
- Большее количество точек взаимодействия с системой увеличивает риск несанкционированного доступа. В то же время при хороших настройках безопасности это может оказаться плюсом, что утеряны будут данные только взломанного микросервиса, а не всей системы.
- Тестирование становится более сложным из-за распределенной природы системы.
👍12❤3🔥2❤🔥1
Итак, для проекта GetDelivery один из вариантов сервисно-ориентированной архитектуры (SOA) может быть реализован так.
Что на схеме архитектуры? 🤔
1. Клиенты
Как и в монолите, список клиентов сохраняется. Единственное, я добавила в этот список панель администратора системы (Web App Admin), чтобы дальше рассказать про отдельные сервисы.
3. Внешние системы
Перечень внешних систем, с которыми необходимо реализовать интеграцию.
Хочу отметить, что на схеме важно показать виды API по которым будет проходить интеграция: REST API, GraphQL, SOAP API, ftp или другие. Пока я этого не сделала, но нужно будет добавить.
Также хочу обратить ваше внимание, что внешняя система - это черный ящик. На схеме архитектуры нашей системы не надо рисовать их БД, если мы о ней ничего не знаем. Мы пользуемся API для интеграций систем доставки с GetDelivery, чтобы не думать об их БД. Ведь именно с целью скрыть прямой доступ к БД СДЭК, Возовоз и Деловые Линии делали публичные API.
2. Backend - серверное приложение с сервисной архитектурой (SOA)
Рассказываю про компоненты и почему они выделены:
- База данных основная - в ней будут храниться все данные связанные с историей поиска, оформленными заказами и всем тем, что связано с базовой функциональностью системы GetDelivery. PostgreSQL.
- База данных пользователей - в ней будем хранить список зарегистрированных пользователей, историю входов в приложения, ключи (токены) доступа и другие данные, связанные с регистрацией и авторизацией пользователей. PostgreSQL.
- Файловое хранилище отчетов - выделено для хранение файлов PDF отчетов о сформированных заказах и других видах отчетов, которые может генерировать приложение администратора, с использованием соответствующего сервиса генерации отчетов.
Продолжение 👇
Что на схеме архитектуры? 🤔
1. Клиенты
Как и в монолите, список клиентов сохраняется. Единственное, я добавила в этот список панель администратора системы (Web App Admin), чтобы дальше рассказать про отдельные сервисы.
3. Внешние системы
Перечень внешних систем, с которыми необходимо реализовать интеграцию.
Хочу отметить, что на схеме важно показать виды API по которым будет проходить интеграция: REST API, GraphQL, SOAP API, ftp или другие. Пока я этого не сделала, но нужно будет добавить.
Также хочу обратить ваше внимание, что внешняя система - это черный ящик. На схеме архитектуры нашей системы не надо рисовать их БД, если мы о ней ничего не знаем. Мы пользуемся API для интеграций систем доставки с GetDelivery, чтобы не думать об их БД. Ведь именно с целью скрыть прямой доступ к БД СДЭК, Возовоз и Деловые Линии делали публичные API.
2. Backend - серверное приложение с сервисной архитектурой (SOA)
Рассказываю про компоненты и почему они выделены:
- База данных основная - в ней будут храниться все данные связанные с историей поиска, оформленными заказами и всем тем, что связано с базовой функциональностью системы GetDelivery. PostgreSQL.
- База данных пользователей - в ней будем хранить список зарегистрированных пользователей, историю входов в приложения, ключи (токены) доступа и другие данные, связанные с регистрацией и авторизацией пользователей. PostgreSQL.
- Файловое хранилище отчетов - выделено для хранение файлов PDF отчетов о сформированных заказах и других видах отчетов, которые может генерировать приложение администратора, с использованием соответствующего сервиса генерации отчетов.
Продолжение 👇
👍20❤3🥰2
Продолжение - переход от монолита к SOA 👇
2. Backend - серверное приложение с сервисной архитектурой (SOA)
Рассказываю про компоненты и почему они выделены:
🔺 Сервис основной логики -
основные функции системы, которые не относятся к остальным сервисам системы. Это подобие монолита внутри сервисной архитектуры и именно так система может выглядеть в промежуточном состоянии при переходе от монолитной архитектуры к SOA или MSA.
🔺 Сервис интеграций с сервисами доставки -
чтобы не грузить ядро системы (сервис основной логики) нагрузкой по запросам к внешним системам, и с учетом того, что в системе-агрегаторе интеграции к внешним системам имеют похожие сценарии по обмену данными, мы выделяем однотипные интеграции в отдельный сервис.
В нем организуем хранение конфигураций для интеграций, общую логику для обработки ошибок и общие функции.
🔺 Сервис авторизации и регистрации пользователей -
так как пользователи, при условиях хорошей реализации требований к безопасности, могут постоянно просить ключи авторизации к системе (например, при требовании к устареванию ключа авторизации каждый час), то лучше выделить эту функциональность в отдельный сервис и держать отдельно от основной логики.
Так мы потенциально снизим количество запросов на основной сервис системы (ядро) в сотни раз, в зависимости от общего объема одновременно работающих пользователей и требований к функциональности авторизации.
Также регистрацию пользователей часто выделяют в отдельный сервис, т.к. за ней может скрываться большой объем данных и настроек пользователей, которые могут создаваться достаточно долго при вызове команды регистрации.
🔺 Сервис генерации отчетов -
предназначен для сбора данных и генерации PDF-файлов на их основе по запросам от приложения администратора. Выделение этого сервиса оправдано тем, что генерация файлов и запись их в файловое хранилище может занять длительное время и лучше это делать на отдельном сервере, выделять под это отдельные мощности.
Этот способ реализации сервисной архитектуры для проекта GetDelivery не единственный. Есть еще варианты деления приложения на сервисы, я показала только один из возможных, с учетом известных сейчас требований к проекту.
Если сравнить исходную схему монолита GetDelivery с полученной картинкой SOA, то можно увидеть наглядно как можно последовательно выделять сервисы от основного бэкенда в отдельные сервисы. Еще раз напомню - на картинке “Сервис основной логики” это монолит, из которого можно выделить еще больше сервисов и микросервисов, когда до конца разберемся с бизнес-процессами и функциональностью системы.
2. Backend - серверное приложение с сервисной архитектурой (SOA)
Рассказываю про компоненты и почему они выделены:
🔺 Сервис основной логики -
основные функции системы, которые не относятся к остальным сервисам системы. Это подобие монолита внутри сервисной архитектуры и именно так система может выглядеть в промежуточном состоянии при переходе от монолитной архитектуры к SOA или MSA.
🔺 Сервис интеграций с сервисами доставки -
чтобы не грузить ядро системы (сервис основной логики) нагрузкой по запросам к внешним системам, и с учетом того, что в системе-агрегаторе интеграции к внешним системам имеют похожие сценарии по обмену данными, мы выделяем однотипные интеграции в отдельный сервис.
В нем организуем хранение конфигураций для интеграций, общую логику для обработки ошибок и общие функции.
🔺 Сервис авторизации и регистрации пользователей -
так как пользователи, при условиях хорошей реализации требований к безопасности, могут постоянно просить ключи авторизации к системе (например, при требовании к устареванию ключа авторизации каждый час), то лучше выделить эту функциональность в отдельный сервис и держать отдельно от основной логики.
Так мы потенциально снизим количество запросов на основной сервис системы (ядро) в сотни раз, в зависимости от общего объема одновременно работающих пользователей и требований к функциональности авторизации.
Также регистрацию пользователей часто выделяют в отдельный сервис, т.к. за ней может скрываться большой объем данных и настроек пользователей, которые могут создаваться достаточно долго при вызове команды регистрации.
🔺 Сервис генерации отчетов -
предназначен для сбора данных и генерации PDF-файлов на их основе по запросам от приложения администратора. Выделение этого сервиса оправдано тем, что генерация файлов и запись их в файловое хранилище может занять длительное время и лучше это делать на отдельном сервере, выделять под это отдельные мощности.
Этот способ реализации сервисной архитектуры для проекта GetDelivery не единственный. Есть еще варианты деления приложения на сервисы, я показала только один из возможных, с учетом известных сейчас требований к проекту.
Если сравнить исходную схему монолита GetDelivery с полученной картинкой SOA, то можно увидеть наглядно как можно последовательно выделять сервисы от основного бэкенда в отдельные сервисы. Еще раз напомню - на картинке “Сервис основной логики” это монолит, из которого можно выделить еще больше сервисов и микросервисов, когда до конца разберемся с бизнес-процессами и функциональностью системы.
👍9❤3👏2
🌟 Визуализация - ключ к пониманию архитектуры систем 🌟
Сложность архитектуры программных систем растет, и чтобы разобраться в ней, системным аналитикам становится важно уметь её визуализировать. Подумайте о сложных системах, вроде Яндекс.Такси, Озон, YouTube, с их множеством компонентов внутри, предназначенных для реализации различных задач.
При рисовании схемы архитектуры, в которой 20 сервисов и 30 микросервисов на Backend часто встает вопрос: как же все это показать и уместить в одну схему?
При создании архитектурных схем используются разные подходы и нотации.
Среди нотаций можно выделить:
🌟 C4,
🌟 ArchiMate,
🌟 SysML,
🌟 4+1,
🌟 AADL.
Выбор зависит от особенностей проекта и предпочтений команды.
Узнать больше о каждой нотации и получить советы по их применению можно в моей статье: Архитектура систем для аналитиков: ТОП-5 нотаций моделирования архитектуры.
Сложность архитектуры программных систем растет, и чтобы разобраться в ней, системным аналитикам становится важно уметь её визуализировать. Подумайте о сложных системах, вроде Яндекс.Такси, Озон, YouTube, с их множеством компонентов внутри, предназначенных для реализации различных задач.
При рисовании схемы архитектуры, в которой 20 сервисов и 30 микросервисов на Backend часто встает вопрос: как же все это показать и уместить в одну схему?
При создании архитектурных схем используются разные подходы и нотации.
Среди нотаций можно выделить:
🌟 C4,
🌟 ArchiMate,
🌟 SysML,
🌟 4+1,
🌟 AADL.
Выбор зависит от особенностей проекта и предпочтений команды.
Узнать больше о каждой нотации и получить советы по их применению можно в моей статье: Архитектура систем для аналитиков: ТОП-5 нотаций моделирования архитектуры.
❤4👍1
Для системного аналитика важно понимать, как проектировать интеграции:
🔹 исследовать API,
🔹 разрабатывать сценарии работы системы, встраивая в них вызовы соответствующих API методов,
🔹 описывать архитектуру,
🔹 разрабатывать маппинги данных,
🔹 проверять как работает API внешних систем, используя Postman, чтобы лучше разбираться в технических деталях,
🔹 как документировать требования и ставить задачи.
Понимание принципов взаимодействия систем и обмена данными на всех уровнях - ключевой навык для участия в сложных и интересных проектах.
На практическом курсе "Проектирование интеграций" мы разберем все эти темы максимально подробно, чтобы вы могли рассказывать о своих знаниях на примере конкретного проекта и переиспользовать их в своих проектах.
👉 25 часов онлайн-практики в течение 2-х месяцев, где вы задаете вопросы и получаете ответы!
👉 Обратная связь по вашей работе онлайн с экспертами и обратной связью сразу, в моменте: мы даем теорию и пример, вы решаете задачу, и мы даем направление, чтобы у вас всё получалось самостоятельно!
Hard-skills по интеграциям и пониманию базовых принципов архитектуры систем - важнейший шаг для карьеры системного аналитика. Возможность освоить новые навыки на практике 👇
🗓 Предзапись на специальных условиях открыта до 10 декабря
🔹 исследовать API,
🔹 разрабатывать сценарии работы системы, встраивая в них вызовы соответствующих API методов,
🔹 описывать архитектуру,
🔹 разрабатывать маппинги данных,
🔹 проверять как работает API внешних систем, используя Postman, чтобы лучше разбираться в технических деталях,
🔹 как документировать требования и ставить задачи.
Понимание принципов взаимодействия систем и обмена данными на всех уровнях - ключевой навык для участия в сложных и интересных проектах.
На практическом курсе "Проектирование интеграций" мы разберем все эти темы максимально подробно, чтобы вы могли рассказывать о своих знаниях на примере конкретного проекта и переиспользовать их в своих проектах.
👉 25 часов онлайн-практики в течение 2-х месяцев, где вы задаете вопросы и получаете ответы!
👉 Обратная связь по вашей работе онлайн с экспертами и обратной связью сразу, в моменте: мы даем теорию и пример, вы решаете задачу, и мы даем направление, чтобы у вас всё получалось самостоятельно!
Hard-skills по интеграциям и пониманию базовых принципов архитектуры систем - важнейший шаг для карьеры системного аналитика. Возможность освоить новые навыки на практике 👇
🗓 Предзапись на специальных условиях открыта до 10 декабря
👍3👏1
GetDelivery - GetAnalyt - MSA.png
167.3 KB
Пример архитектуры MSA для проекта GetDelivery 👀📌 Этот пост надо сохранить!
Для проекта GetDelivery один из вариантов микросервисной архитектуры (MSA) может быть реализован так, как показано на приложенной схеме. Загружайте себе файл с примером и изучайте.
Сразу хочу заметить, что при детальном знакомстве со схемой, чистой микросервисной архитектуры вы не найдёте.
В проектах, с которыми я работала, были такие комбинации:
- Монолит,
- Сервисы,
- Монолит + Сервисы,
- Монолит + Микросервисы,
- Монолит + Сервисы + Микросервисы.
- Сервисы + Микросервисы.
В реальных проектах делают смесь архитектурных подходов. Это нормально.
На приложенной картинке я выделила понятные по требованиям микросервисы, а всё остальное приняла решение отправить в общие сервисы, потому что какой-то специфичной функциональности пока не выделила.
Если будем принимать оплату через нашу систему, то обязательно добавим в GetDelivery интеграционный сервис приема платежей. Интеграция в нем будет с платежной системой.
Кстати, бывает сложно доказать, что микросервис на самом деле микро- 😁 В этом главный подвох микросервисной архитектуры. Когда сервис уже микро-, но ещё не нано-сервис?! 🙈
При проектировании микросервисной архитектуры нужна опытная команда и оптимальные решения, которые принимаются с учетом понимания функциональности всего проекта.
Системные аналитики в процессе проектирования архитектуры помогают разработчикам и архитекторам с пониманием общей картины по функциональности проекта и разъяснением бизнес-потребностей, которые влияют на технические решения.
Для проекта GetDelivery один из вариантов микросервисной архитектуры (MSA) может быть реализован так, как показано на приложенной схеме. Загружайте себе файл с примером и изучайте.
Сразу хочу заметить, что при детальном знакомстве со схемой, чистой микросервисной архитектуры вы не найдёте.
В проектах, с которыми я работала, были такие комбинации:
- Монолит,
- Сервисы,
- Монолит + Сервисы,
- Монолит + Микросервисы,
- Монолит + Сервисы + Микросервисы.
- Сервисы + Микросервисы.
В реальных проектах делают смесь архитектурных подходов. Это нормально.
На приложенной картинке я выделила понятные по требованиям микросервисы, а всё остальное приняла решение отправить в общие сервисы, потому что какой-то специфичной функциональности пока не выделила.
Если будем принимать оплату через нашу систему, то обязательно добавим в GetDelivery интеграционный сервис приема платежей. Интеграция в нем будет с платежной системой.
Кстати, бывает сложно доказать, что микросервис на самом деле микро- 😁 В этом главный подвох микросервисной архитектуры. Когда сервис уже микро-, но ещё не нано-сервис?! 🙈
При проектировании микросервисной архитектуры нужна опытная команда и оптимальные решения, которые принимаются с учетом понимания функциональности всего проекта.
Системные аналитики в процессе проектирования архитектуры помогают разработчикам и архитекторам с пониманием общей картины по функциональности проекта и разъяснением бизнес-потребностей, которые влияют на технические решения.
🔥8👍4❤2😁2❤🔥1
Какую архитектуру выбрать для проекта? 🧐
🟡 Принятие решений по организации архитектуры системы должно быть обосновано и учитывать не только текущие, но и будущие потребности бизнеса, особенно в контексте нефункциональных требований.
🟡 Нефункциональные требования напрямую влияют на подход к проектированию архитектуры.
Это требования не к тому, что система должна делать, а к тому, как она должна это делать.
Примеры:
+ Система должна сохранять одинаковую скорость отклика при нагрузке до 100 пользователей в 1 сек.
+ Обновление подсистемы интеграции со СДЭК не должно вызывать остановку работы остальных интеграций.
+ Доступность системы должна быть 99% времени в год. То есть допустим простой до 88 часов в год.
+ Время отклика системы на любой запрос не должно превышать 500 миллисекунд, если для него нет интеграций с внешними системами. В случае, если в процессе выполнения запроса принимает участие внешняя система, то время отклика может быть выше, и зависит от времени ожидания ответа от неё.
🟡 Процесс принятия решений по архитектуре проекта:
1. Собираем требования: узнаем у бизнеса, что от системы ожидают.
2. Анализируем требования: понимаем, какие есть ограничения и возможности, продумываем и согласуем бизнес-требования, функциональные и нефункциональные требования.
3. Выбираем архитектуру: определяем, какой тип архитектуры подходит под задачи.
4. Выделяем компоненты, которые будут решать задачи системы и выполнять её функции, а затем отражаем решения на схеме архитектуры.
5. Идем далее на этап детализации требований.
Продолжение 👇
🟡 Принятие решений по организации архитектуры системы должно быть обосновано и учитывать не только текущие, но и будущие потребности бизнеса, особенно в контексте нефункциональных требований.
🟡 Нефункциональные требования напрямую влияют на подход к проектированию архитектуры.
Это требования не к тому, что система должна делать, а к тому, как она должна это делать.
Примеры:
+ Система должна сохранять одинаковую скорость отклика при нагрузке до 100 пользователей в 1 сек.
+ Обновление подсистемы интеграции со СДЭК не должно вызывать остановку работы остальных интеграций.
+ Доступность системы должна быть 99% времени в год. То есть допустим простой до 88 часов в год.
+ Время отклика системы на любой запрос не должно превышать 500 миллисекунд, если для него нет интеграций с внешними системами. В случае, если в процессе выполнения запроса принимает участие внешняя система, то время отклика может быть выше, и зависит от времени ожидания ответа от неё.
🟡 Процесс принятия решений по архитектуре проекта:
1. Собираем требования: узнаем у бизнеса, что от системы ожидают.
2. Анализируем требования: понимаем, какие есть ограничения и возможности, продумываем и согласуем бизнес-требования, функциональные и нефункциональные требования.
3. Выбираем архитектуру: определяем, какой тип архитектуры подходит под задачи.
4. Выделяем компоненты, которые будут решать задачи системы и выполнять её функции, а затем отражаем решения на схеме архитектуры.
5. Идем далее на этап детализации требований.
Продолжение 👇
❤8👍2👎1