Буквально вчера я встретила знакомую в спортзале и на моё “Как дела?” она сказала:
“Пойдёт. Возможно я перееду из Калифорнии. Пока не знаю куда. Но я точно знаю, что будут изменения. Я чувствую, что по-старому мне уже не нравится и знаю, что хочу и сделаю свою жизнь другой. Но пока не знаю как это будет. Чувствую, что это переходный период.”
И так мне оказалась знакома эта история. Моя история.
“Мне не нравится сидеть на месте. Я устала от однообразия. Хочется что-то новое, лучшее. Я пока не знаю как и что, но всё будет по-другому. Рутина и однообразие - не моё, мне скучно!”
В последний раз я сказала себе это летом 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
Какой тип архитектуры выбрать? 🙄
🔺 Монолит:
Как один большой блок. Подходит для маленьких проектов и стартапов. Такие системы просты в реализации, но их сложно менять и развивать. Это может быть плохое решение при наличии строгих нефункциональных требований: скорость работы, нагрузки, масштабируемость и другие.
🔺 SOA (Сервисно-ориентированная):
Разбивает систему на несколько крупных частей.
Подход хорош для больших продуктов, где много разных сервисов и нужно распределять нагрузку, делать независимые обновления с возможностью останавливать работу отдельных блоков функциональности, при необходимости.
🔺 Микросервисы:
Много маленьких сервисов, каждый делает что-то одно - выполняет свою микро-задачу.
Удобно, когда надо часто менять или добавлять новую функциональность, при этом держать всю систему в рабочем состоянии по максимуму.
Часто применяется в банковских проектах и высокопроизводительных системах с кучей расчетов в режиме реального времени.
При всех преимуществах в масштабировании, обслуживании и сопровождении, такая архитектура может быть избыточна в системах без высокой нагрузки и высокой чувствительности к данным.
Также есть сложности в синхронизации данных. между разными БД.
И моё любимое ❤️:
Выбор подхода к архитектуре зависит от проекта. Для GetDelivery подойдет и сервисная, и монолитная архитектура.
Микросервисная будет избыточна, т.к. сделает стоимость проекта дороже, но плюсов не принесёт, а только усложнит логику работы системы.
Но т.к. я не хочу держать интеграции и основную логику приложения в одном месте, то я выберу SOA-подход для нашего проекта - с сервисной архитектурой.
🔺 Монолит:
Как один большой блок. Подходит для маленьких проектов и стартапов. Такие системы просты в реализации, но их сложно менять и развивать. Это может быть плохое решение при наличии строгих нефункциональных требований: скорость работы, нагрузки, масштабируемость и другие.
🔺 SOA (Сервисно-ориентированная):
Разбивает систему на несколько крупных частей.
Подход хорош для больших продуктов, где много разных сервисов и нужно распределять нагрузку, делать независимые обновления с возможностью останавливать работу отдельных блоков функциональности, при необходимости.
🔺 Микросервисы:
Много маленьких сервисов, каждый делает что-то одно - выполняет свою микро-задачу.
Удобно, когда надо часто менять или добавлять новую функциональность, при этом держать всю систему в рабочем состоянии по максимуму.
Часто применяется в банковских проектах и высокопроизводительных системах с кучей расчетов в режиме реального времени.
При всех преимуществах в масштабировании, обслуживании и сопровождении, такая архитектура может быть избыточна в системах без высокой нагрузки и высокой чувствительности к данным.
Также есть сложности в синхронизации данных. между разными БД.
И моё любимое ❤️:
Выбор подхода к архитектуре зависит от проекта. Для GetDelivery подойдет и сервисная, и монолитная архитектура.
Микросервисная будет избыточна, т.к. сделает стоимость проекта дороже, но плюсов не принесёт, а только усложнит логику работы системы.
Но т.к. я не хочу держать интеграции и основную логику приложения в одном месте, то я выберу SOA-подход для нашего проекта - с сервисной архитектурой.
🔥9😍3👍1👎1
This media is not supported in your browser
VIEW IN TELEGRAM
Тяжело быть IT-ишником, знаете 😅
Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘
Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘
🤣11🔥8
Коллеги, всем привет!
Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.
То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).
Пока я намеренно упустила часть обозначений, которые обычно использую:
- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).
- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.
Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.
Я с огромным уважением отношусь к авторам стандартов и стараюсь их придерживаться во всех своих схемах. Знания UML и С4 - это фундаментальные знания, на которые я опираюсь в процессе создания любых диаграмм и схем.
Я хочу показать для вас как будет переведена наша схема в общепринтую международную нотацию, про которую могут спрашивать специалистов на собеседованиях. Это C4 - нотация моделирования архитектуры.
Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.
То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).
Пока я намеренно упустила часть обозначений, которые обычно использую:
- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).
- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.
Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.
Я с огромным уважением отношусь к авторам стандартов и стараюсь их придерживаться во всех своих схемах. Знания UML и С4 - это фундаментальные знания, на которые я опираюсь в процессе создания любых диаграмм и схем.
Я хочу показать для вас как будет переведена наша схема в общепринтую международную нотацию, про которую могут спрашивать специалистов на собеседованиях. Это C4 - нотация моделирования архитектуры.
❤13👍6👎1🤣1
Нотация C4 (Model for Software Architecture) — это метод визуализации архитектуры программного обеспечения, разработанный Саймоном Брауном.
Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.
C4 появилась как реакция на сложность и непонятность традиционных архитектурных диаграмм. Саймон Браун предложил этот подход в начале 2010-х годов с целью упростить понимание архитектуры для всех участников команды разработки, включая обычных разработчиков, тестировщиков, аналитиков, менеджеров и других заинтересованных сторон.
Уровни Представления:
🔺 Уровень системы (System Context diagram)
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Обычно используют на начальных этапах проектирования, для понимания общего контекста.
Элементы:
- системы,
- пользователи,
- взаимосвязи.
🔺 Уровень контейнеров (Container diagram)
Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.
Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.
🔺 Уровень компонентов (Component diagram)
Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один контейнер из предыдущего уровня.
Используется для проектирования и документирования внутренней структуры компонентов системы.
Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.
🔺 Уровень кода (Code diagram)
Показывает детали реализации отдельных компонентов.
Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.
Элементы:
- классы,
- интерфейсы,
- отношения между ними.
❤️ Красивая схема C4 в Miro c примером проекта.
Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.
C4 появилась как реакция на сложность и непонятность традиционных архитектурных диаграмм. Саймон Браун предложил этот подход в начале 2010-х годов с целью упростить понимание архитектуры для всех участников команды разработки, включая обычных разработчиков, тестировщиков, аналитиков, менеджеров и других заинтересованных сторон.
Уровни Представления:
🔺 Уровень системы (System Context diagram)
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Обычно используют на начальных этапах проектирования, для понимания общего контекста.
Элементы:
- системы,
- пользователи,
- взаимосвязи.
🔺 Уровень контейнеров (Container diagram)
Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.
Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.
🔺 Уровень компонентов (Component diagram)
Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один контейнер из предыдущего уровня.
Используется для проектирования и документирования внутренней структуры компонентов системы.
Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.
🔺 Уровень кода (Code diagram)
Показывает детали реализации отдельных компонентов.
Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.
Элементы:
- классы,
- интерфейсы,
- отношения между ними.
❤️ Красивая схема C4 в Miro c примером проекта.
🔥12❤5👍3👎1
Показываю интересное - как сделать C4 через PlantUML за 1 минуту! 🙂
🔺 C4 - Context
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Код для реализации уровня C4 - Context для проекта GetDelivery.
------------
------------
🟡 В этой диаграмме:
- Пользователи (администратор и конечный пользователь) взаимодействуют с системой GetDelivery.
- Система GetDelivery интегрируется с внешними сервисами доставки: СДЭК, Возовоз и Деловые Линии.
- Все интеграции осуществляются через API с использованием HTTPS/JSON.
🟡 Для визуализации этой диаграммы:
1. Скопируйте и вставьте приведенный выше код в редактор PlantUML.
2. Диаграмма будет сгенерирована автоматически.
* Если ловите ошибку открытия ссылки (строка 2), то подождите несколько минут или попереключайтесь между режимами светлая-темная тема, попробуйте другой браузер. К сожалению, PlantUml имеет небольшие проблемы с открытием ссылок и это самый простой способ их исправить.
У кого получилось визуализировать - ставьте ❤️ под пост!
🔺 C4 - Context
Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.
Код для реализации уровня C4 - Context для проекта GetDelivery.
------------
@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
LAYOUT_WITH_LEGEND()
Person(admin, "Администратор", "Управляет системой через Web App Admin.")
Person(user, "Пользователь", "Использует систему для отслеживания и управления доставками.")
System_Ext(sdek, "СДЭК", "Внешняя система доставки.")
System_Ext(vozovoz, "Возовоз", "Внешняя система доставки.")
System_Ext(delovyeLinii, "Деловые Линии", "Внешняя система доставки.")
System(getDelivery, "GetDelivery", "Система GetDelivery с сервисно-ориентированной архитектурой (SOA).")
Rel(admin, getDelivery, "Использует", "HTTPS")
Rel(user, getDelivery, "Использует", "HTTPS")
Rel(getDelivery, sdek, "Интеграция через API", "HTTPS/JSON")
Rel(getDelivery, vozovoz, "Интеграция через API", "HTTPS/JSON")
Rel(getDelivery, delovyeLinii, "Интеграция через API", "HTTPS/JSON")
@enduml------------
🟡 В этой диаграмме:
- Пользователи (администратор и конечный пользователь) взаимодействуют с системой GetDelivery.
- Система GetDelivery интегрируется с внешними сервисами доставки: СДЭК, Возовоз и Деловые Линии.
- Все интеграции осуществляются через API с использованием HTTPS/JSON.
🟡 Для визуализации этой диаграммы:
1. Скопируйте и вставьте приведенный выше код в редактор PlantUML.
2. Диаграмма будет сгенерирована автоматически.
* Если ловите ошибку открытия ссылки (строка 2), то подождите несколько минут или попереключайтесь между режимами светлая-темная тема, попробуйте другой браузер. К сожалению, PlantUml имеет небольшие проблемы с открытием ссылок и это самый простой способ их исправить.
У кого получилось визуализировать - ставьте ❤️ под пост!
🔥14❤6
Просто бери и делай ☑️✅👌
Возможности менять себя и свою жизнь к лучшему есть всегда. Но были моменты, когда я тормозила, или пробовала отойти назад. Почему? Я испытывала страх.
🎲 Когда я получила оффер в первую компанию на позицию стажера-аналитика, то хотела отказаться. Так как я в один момент уронила свою зарплату в 4 раза и увеличила время работы с 20 до 40 часов в неделю.
В итоге я согласилась через внутреннее "не хочу", потому что я понимала - преподавательская деяельность для школьников+студентов и мелкие проекты без официального трудоустройства мне карьеру не сделают.
В итоге руковожу в ИТ. Побывала на позициях старшего аналитика, ведущего аналитика, руководителя отдела, технического руководителя проектов (СТО), собственник ИТ-бизнеса, основатель ИТ-сообщества.
А страшно то как было... Зачем я это сделала? В 2023 стало точно понятно зачем.
🎲 Кому нужно то, что я пишу? Какой образовательный проект по системному анализу? Что за странная идея у меня в голове? На первых открытых вебинарах было 6-10 человек, не самая уверенная речь, куча времени на подготовки и боязнь вопросов. А вдруг я не знаю? В блоге не ясно что писать.
За 2.5 года GetAnalyst стал интереснее и прошел несколько стадий преобразования. Нас тут почти 5000 и мои посты выходят 5-7 дней в неделю. Много статей и структурированной информации. Работаем дальше. Есть еще что делать.
Это лишь пара примеров из одной жизни.
Мне страшно менять жизнь, я вечно сомневаюсь в решениях. Не похоже? Потому что это внутри, а снаружи я включаю смелую Катерину и действую: через «страшно», через «не могу», через «не хочу». Потому что знаю, что действия дают результат и не вызывают чувства "я жалею, что не попробовала" в будущем.
Для меня ничего не делать хуже, чем ошибиться 😰 Самые сложные шаги часто связаны с выходом из привычного, комфортного состояния.
👇👇👇
Возможности менять себя и свою жизнь к лучшему есть всегда. Но были моменты, когда я тормозила, или пробовала отойти назад. Почему? Я испытывала страх.
В итоге я согласилась через внутреннее "не хочу", потому что я понимала - преподавательская деяельность для школьников+студентов и мелкие проекты без официального трудоустройства мне карьеру не сделают.
В итоге руковожу в ИТ. Побывала на позициях старшего аналитика, ведущего аналитика, руководителя отдела, технического руководителя проектов (СТО), собственник ИТ-бизнеса, основатель ИТ-сообщества.
А страшно то как было... Зачем я это сделала? В 2023 стало точно понятно зачем.
За 2.5 года GetAnalyst стал интереснее и прошел несколько стадий преобразования. Нас тут почти 5000 и мои посты выходят 5-7 дней в неделю. Много статей и структурированной информации. Работаем дальше. Есть еще что делать.
Это лишь пара примеров из одной жизни.
Мне страшно менять жизнь, я вечно сомневаюсь в решениях. Не похоже? Потому что это внутри, а снаружи я включаю смелую Катерину и действую: через «страшно», через «не могу», через «не хочу». Потому что знаю, что действия дают результат и не вызывают чувства "я жалею, что не попробовала" в будущем.
Для меня ничего не делать хуже, чем ошибиться 😰 Самые сложные шаги часто связаны с выходом из привычного, комфортного состояния.
👇👇👇
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🥰8❤4👎1
Каждый раз, когда мы хотим меняться важно помнить: результаты без усилий невозможны 🙌
Сомнения: "А нужно ли это?", "Мне и так хорошо", "А вдруг не получится?" - это нормально, но это то, что нас тормозит.
Многие люди так и остаются в своем текущем состоянии из-за страха. Но зачем бояться? Можно же просто ввязаться в игру и действовать!
Несколько рекомендаций, которыми я пользуюсь в своей жизни, чтобы двигаться вперёд и не стоять на месте:
1. Сталкиваясь со страхом перед новым, напоминайте себе, что ничего не делать хуже, чем ошибиться. Не лишайте себя шансов.
2. Не поддавайтесь сомнениям, действуйте. "А если не получится..." замените на фразу "Когда я это сделаю, то...".
3. Планируйте: записывайте задачи, которые помогут прийти к цели, и время их выполнения.
3.1. Создайте свою систему "время-место-галочка" для преодоления страхов, чтобы оставить сомнения и двигаться вперед.
Отмечайте галочки у выполненных задач. Так вы будете видеть прогресс. Даже когда кажется, что его нет.
Хотите меняться, но сомневаетесь? Не надо сомневаться. Нравится? Берите, пробуйте и воплощайте мечты в жизнь! Всё будет! ❤️
Сомнения: "А нужно ли это?", "Мне и так хорошо", "А вдруг не получится?" - это нормально, но это то, что нас тормозит.
Многие люди так и остаются в своем текущем состоянии из-за страха. Но зачем бояться? Можно же просто ввязаться в игру и действовать!
Несколько рекомендаций, которыми я пользуюсь в своей жизни, чтобы двигаться вперёд и не стоять на месте:
1. Сталкиваясь со страхом перед новым, напоминайте себе, что ничего не делать хуже, чем ошибиться. Не лишайте себя шансов.
2. Не поддавайтесь сомнениям, действуйте. "А если не получится..." замените на фразу "Когда я это сделаю, то...".
3. Планируйте: записывайте задачи, которые помогут прийти к цели, и время их выполнения.
3.1. Создайте свою систему "время-место-галочка" для преодоления страхов, чтобы оставить сомнения и двигаться вперед.
Отмечайте галочки у выполненных задач. Так вы будете видеть прогресс. Даже когда кажется, что его нет.
Хотите меняться, но сомневаетесь? Не надо сомневаться. Нравится? Берите, пробуйте и воплощайте мечты в жизнь! Всё будет! ❤️
🔥20👍8❤🔥1👎1
💫 Собрала теорию, примеры и инструменты для визуализации C4 в одну статью 💫
Что получилось:
1. Краткая сводка по теории.
2. Собранные в одном месте примеры диаграмм С4 (несколько для каждого уровня), на которых можно осваивать нотацию.
3. Подборка инструментов для создания схем архитектуры C4.
4. Подборка дополнительных материалов.
5. Заключение по применению C4 в процессе проектирования архитектуры.
➡️ Читать на Habr
Что получилось:
1. Краткая сводка по теории.
2. Собранные в одном месте примеры диаграмм С4 (несколько для каждого уровня), на которых можно осваивать нотацию.
3. Подборка инструментов для создания схем архитектуры C4.
4. Подборка дополнительных материалов.
5. Заключение по применению C4 в процессе проектирования архитектуры.
➡️ Читать на Habr
Хабр
Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты
Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Популярные нотации для визуализации схем архитектуры: C4, ArchiMate, SysML, 4+1, AADL....
🔥12❤8👍1🥰1👌1
Непрерывно изучать новое для участия в крутых и интересных проектах - необходимость в IT.
Понимание принципов взаимодействия систем, интеграций, базовых принципов организации архитектуры, и умение применить их на практике, в процессе разработки сценариев работы системы и постановки задач на разработчиков - важные навыки для системных аналитиков.
Поэтому мы готовим для вас новый практический вебинар, чтобы показать, как системному аналитику работать с задачами на проектирование интеграций!
📝 Интеграции: как создавать задачи на разработчиков
📅 12 декабря, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
В программе:
1️⃣ Знакомство с задачей на интеграцию систем и API-документацией для её реализации.
2️⃣ Проектирование архитектуры взаимодействия.
3️⃣ Разработка интеграционного Use Case.
4️⃣ Создание задач на БД, Backend и Frontend.
➕ особенности, про маппинг данных, подвохи и ответы на ваши вопросы!
Хотите освоить новые подходы к решению интеграционных задач и проверить свой опыт?
Регистрируйтесь и приходите онлайн! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👌6❤2🥰2
3️⃣ Анализ API-документации
Идём по плану. Работу с верхнеуровневым проектированием архитектуры завершили. Теперь нужно изучать API.
В работе с интеграционным проектом, важнейшим этапом является анализ API-документации партнеров: СДЭК, Возовоз и Деловые линии. Системному аналитику важно понимание их API.
Попытка описывать функциональность системы с интеграциями без детального изучения API-документации может привести к рискам в процессе разработки:
✖️ Нет нужных методов, чтобы реализовать получение или запись данных во внешней системе.
✖️ Нет нужных данных: метод для реализации функциональности есть, но данных для нашей системы недостаточно и нужно проявить изобретательность, чтобы всё получилось, либо идти на переговоры к партнерам.
✖️ Обрабатываете не все ошибки и исключительные ситуации, которые являются нормальными в системе партнера, но для вас никогда не были реализованы.
✖️ Пытаетесь придумать сценарий интеграции сами, хотя в документации партнера есть рекомендации, которые сэкономили бы вам дни работы.
✖️ Проблемы с авторизацией и аутентификацией запросов: не учли, что нужны дополнительные системные или пользовательские авторизации и потеряли логику авторизации запросов.
С каждым риском можно будет разобраться позже. Но скорее всего это уже будут придуманные “костыли” на ходу, вместо заранее продуманного плана действия.
Такая работа похожа на марафон без подготовки: ты ни разу не бегал 42 км, а теперь после 6 км пытаешься придумать на ходу как пробежать ещё 36, и чтобы сердце не отказало сейчас 🏃♀️💀❤️🩹
Идём по плану. Работу с верхнеуровневым проектированием архитектуры завершили. Теперь нужно изучать API.
В работе с интеграционным проектом, важнейшим этапом является анализ API-документации партнеров: СДЭК, Возовоз и Деловые линии. Системному аналитику важно понимание их API.
Попытка описывать функциональность системы с интеграциями без детального изучения API-документации может привести к рискам в процессе разработки:
✖️ Нет нужных методов, чтобы реализовать получение или запись данных во внешней системе.
✖️ Нет нужных данных: метод для реализации функциональности есть, но данных для нашей системы недостаточно и нужно проявить изобретательность, чтобы всё получилось, либо идти на переговоры к партнерам.
✖️ Обрабатываете не все ошибки и исключительные ситуации, которые являются нормальными в системе партнера, но для вас никогда не были реализованы.
✖️ Пытаетесь придумать сценарий интеграции сами, хотя в документации партнера есть рекомендации, которые сэкономили бы вам дни работы.
✖️ Проблемы с авторизацией и аутентификацией запросов: не учли, что нужны дополнительные системные или пользовательские авторизации и потеряли логику авторизации запросов.
С каждым риском можно будет разобраться позже. Но скорее всего это уже будут придуманные “костыли” на ходу, вместо заранее продуманного плана действия.
Такая работа похожа на марафон без подготовки: ты ни разу не бегал 42 км, а теперь после 6 км пытаешься придумать на ходу как пробежать ещё 36, и чтобы сердце не отказало сейчас 🏃♀️💀❤️🩹
❤5👍5