🌱 Микросервисная архитектура (MSA) 🌱
Микросервисная архитектура (MSA - MicroService Architecture) - принцип разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы обычно общаются с другими сервисами через HTTP API, REST API, также наблюдаются тренды внедрения gRPC.
Ключевые особенности MSA и отличия от SOA:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции. Обычно они более специализированы, чем в SOA. В SOA логика одного сервиса может включать широкий набор возможностей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга. То же верно и для SOA.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи. То же, что и в SOA.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы. То же, что и в SOA.
💪 По классическому шаблону MSA для каждого микросервиса делают свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
Примеры мировых проектов с MSA:
🔸 Netflix: микросервисы для стриминга видео, рекомендаций контента, управления профилями пользователей и другие.
🔸 Amazon: сервисы управления заказами, обработки платежей, управления каталогом товаров и другие.
🔸 Банковская сфера: микросервисы аутентификации и авторизации, управления счетами, уведомлений и другие.
Ключевые отличия между SOA и MSA показала на прикрепленной к посту картинке. Раскроем каждый пункт по особенностям SOA в следующем посте сегодня 😉
#АрхитектураGA
Микросервисная архитектура (MSA - MicroService Architecture) - принцип разработки программного обеспечения, в котором сложное приложение разбивается на небольшие, независимые части, выполняющие конкретные функции. Эти части называют микросервисами.
Микросервисы обычно общаются с другими сервисами через HTTP API, REST API, также наблюдаются тренды внедрения gRPC.
Ключевые особенности MSA и отличия от SOA:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции. Обычно они более специализированы, чем в SOA. В SOA логика одного сервиса может включать широкий набор возможностей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга. То же верно и для SOA.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи. То же, что и в SOA.
💪 Ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы. То же, что и в SOA.
💪 По классическому шаблону MSA для каждого микросервиса делают свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
Примеры мировых проектов с MSA:
🔸 Netflix: микросервисы для стриминга видео, рекомендаций контента, управления профилями пользователей и другие.
🔸 Amazon: сервисы управления заказами, обработки платежей, управления каталогом товаров и другие.
🔸 Банковская сфера: микросервисы аутентификации и авторизации, управления счетами, уведомлений и другие.
Ключевые отличия между SOA и MSA показала на прикрепленной к посту картинке. Раскроем каждый пункт по особенностям SOA в следующем посте сегодня 😉
#АрхитектураGA
⚡13👍11🔥4❤3
🌱 Микросервисная архитектура (MSA) - детальный разбор с примерами 🌱
Микросервисная архитектура представляет собой решение, позволяющее эффективно адаптироваться к быстро меняющимся требованиям и масштабироваться при росте пользователей и функций в системе.
Разбираем ключевые особенности на примерах:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции.
Другими словами, каждый сервис будет отвечать за работу с одной конкретной сущностью или узконаправленной функциональностью.
В TelMed можно выделить микросервисы управление записями на приём, управления записями о докторах, обработки платежей. В SOA сервисы управления записями на приём и докторами могли бы быть объединены в один сервис общей логики.
Микросервис управления перс. данными пациентов строится вокруг конкретной бизнес-потребности — обеспечение безопасности и конфиденциальности, в соответствии с требованиями закона о защите данных. Он занимается только этой узконаправленной задачей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга.
Над микросервисами управления медицинскими картами, врачей и видеоконсультаций могут работать разные команды параллельно.
Тестирование, программирование и релизы совершенно не пересекаются, и команды могут не бояться задеть друг-друга или внести несовместимые изменения в код. Это разные кодовые базы.
Проблемы возможны только при наличии внутренних интеграций, если изменения касаются состава данных, которые передаются из одного микросервиса в другой.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи.
В одном микросервисе могут использовать реляционную СУБД PostgreSQL, в то время как для другого подберут нереляционную СУБД MongoDB.
То же верно и для языков программирования.
Но по опыту скажу, что стараются держать общие подходы на весь проект и не устраивать зоопарк из технологий.
Продолжение 👇
#АрхитектураGA #TelMedGA
Микросервисная архитектура представляет собой решение, позволяющее эффективно адаптироваться к быстро меняющимся требованиям и масштабироваться при росте пользователей и функций в системе.
Разбираем ключевые особенности на примерах:
💪 Приложение разделяется на множество небольших сервисов, каждый из которых отвечает за выполнение конкретной бизнес-функции.
Другими словами, каждый сервис будет отвечать за работу с одной конкретной сущностью или узконаправленной функциональностью.
В TelMed можно выделить микросервисы управление записями на приём, управления записями о докторах, обработки платежей. В SOA сервисы управления записями на приём и докторами могли бы быть объединены в один сервис общей логики.
Микросервис управления перс. данными пациентов строится вокруг конкретной бизнес-потребности — обеспечение безопасности и конфиденциальности, в соответствии с требованиями закона о защите данных. Он занимается только этой узконаправленной задачей.
💪 Сервисы могут разрабатываться, тестироваться и развертываться независимо друг от друга.
Над микросервисами управления медицинскими картами, врачей и видеоконсультаций могут работать разные команды параллельно.
Тестирование, программирование и релизы совершенно не пересекаются, и команды могут не бояться задеть друг-друга или внести несовместимые изменения в код. Это разные кодовые базы.
Проблемы возможны только при наличии внутренних интеграций, если изменения касаются состава данных, которые передаются из одного микросервиса в другой.
💪 Разные микросервисы могут использовать разные технологии и базы данных, оптимизированные под их конкретные задачи.
В одном микросервисе могут использовать реляционную СУБД PostgreSQL, в то время как для другого подберут нереляционную СУБД MongoDB.
То же верно и для языков программирования.
Но по опыту скажу, что стараются держать общие подходы на весь проект и не устраивать зоопарк из технологий.
Продолжение 👇
#АрхитектураGA #TelMedGA
👍12❤3👏3
💪 В микросервисах ошибки в одном сервисе обычно не влияют на работу других сервисов, что повышает надежность всей системы.
Если микросервис платежей отключится, то микросервис поиска докторов это не затронет и пользователи, которые работают с поиском докторов, могут даже не заметить, что какая-то часть системы не работала.
💪 По классическому шаблону MSA для каждого микросервиса делают одну свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
Это позволяет быть микросервисам полностью независимыми. В SOA при обновлении структуры БД могут стать недоступны все связанные с ней сервисы, которых может быть 5. А в MSA при обновлении одной БД может быть недоступен только один связанный с ней микросервис.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
🔸 Два самых важных отличия между SOA и MSA - размеры сервисов и количество БД на один сервис. Остальное во многом схоже.
Знания о микросервисах позволяют аналитикам ставить более точные задачи разработчикам, прогнозировать последствия изменений в функциональности и гарантировать высокую надежность и производительность системы. Аналитики ясно и понятно формулируют технические требования к межсервисному взаимодействию для разработчиков, что значительно повышает качество и ценность их работы для ИТ-компаний.
В связи с этим, для крупных проектов предпочтение отдают системным аналитикам, которые имеют опыт работы с микросервисной архитектурой. Такие специалисты понимают сложности, связанные с синхронизацией данных между различными базами данных и особенности внутренних и внешних интеграций проекта 🙌
#АрхитектураGA #TelMedGA
Если микросервис платежей отключится, то микросервис поиска докторов это не затронет и пользователи, которые работают с поиском докторов, могут даже не заметить, что какая-то часть системы не работала.
💪 По классическому шаблону MSA для каждого микросервиса делают одну свою БД, в то время как для SOA допустимо использование одной БД несколькими сервисами.
Это позволяет быть микросервисам полностью независимыми. В SOA при обновлении структуры БД могут стать недоступны все связанные с ней сервисы, которых может быть 5. А в MSA при обновлении одной БД может быть недоступен только один связанный с ней микросервис.
💪 Микросервисы используют более простые и децентрализованные методы связи как API Gateway, хореограф и оркестратор, в то время как SOA может полагаться на более сложные механизмы, такие как Enterprise Service Bus (ESB).
🔸 Два самых важных отличия между SOA и MSA - размеры сервисов и количество БД на один сервис. Остальное во многом схоже.
Знания о микросервисах позволяют аналитикам ставить более точные задачи разработчикам, прогнозировать последствия изменений в функциональности и гарантировать высокую надежность и производительность системы. Аналитики ясно и понятно формулируют технические требования к межсервисному взаимодействию для разработчиков, что значительно повышает качество и ценность их работы для ИТ-компаний.
В связи с этим, для крупных проектов предпочтение отдают системным аналитикам, которые имеют опыт работы с микросервисной архитектурой. Такие специалисты понимают сложности, связанные с синхронизацией данных между различными базами данных и особенности внутренних и внешних интеграций проекта 🙌
#АрхитектураGA #TelMedGA
👍6❤5💯3
Архитектура для аналитиков: опыт работы здесь 🙌
В этом году я запустила новую практическую программу, которая улучшилась в процессе ведения первого потока и дополнилась огромным количеством дополнительных материалов и разборов примеров.
🌟 Проектирование архитектуры
🌟 Старт предобучения 28 мая 2024
🌟 Подробности о программе и запись
В ней я проявила максимальные занудство и дотошность. Собирала не только свой опыт, но и подключила других экспертов.
Один из важных отзывов, повторяемый разными словами в чатах:
Эта программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, и хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.
🎁 С 15 до 22 маяоткрыта предзапись на специальных условиях + дополнительное обучение по REST API в подарок.
Для всех, кто оставлял запросы до сегодняшнего дня и уже связался с нами, действует аналогичное предложение 🎁
Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу,
+ получать повышения.
Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌
2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!
В этом году я запустила новую практическую программу, которая улучшилась в процессе ведения первого потока и дополнилась огромным количеством дополнительных материалов и разборов примеров.
🌟 Проектирование архитектуры
🌟 Старт предобучения 28 мая 2024
🌟 Подробности о программе и запись
В ней я проявила максимальные занудство и дотошность. Собирала не только свой опыт, но и подключила других экспертов.
Один из важных отзывов, повторяемый разными словами в чатах:
“Есть возможность попрактиковаться в проектировании архитектурного решения, выйти за пределы "пузыря" моей работы и налаженных процессов на работе”
Эта программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, и хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.
🎁 С 15 до 22 мая
Для всех, кто оставлял запросы до сегодняшнего дня и уже связался с нами, действует аналогичное предложение 🎁
Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу,
+ получать повышения.
Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌
2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!
👍10❤3🔥1
🧐 Как определить, что в проекте нужна микросервисная архитектура? 🧐
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
Микросервисную архитектуру стоит рассматривать как решение, если проекту уже несколько лет, он работает как монолит, и наблюдается успешная динамика роста:
+ постоянно внедряется новая функциональность,
+ растет нагрузка и число пользователей.
Также для государственных систем, банков и подобных проектов, где при создании новой системы гарантировано огромное количество пользователей с первых дней работы.
Микросервисы идеальны:
✅ Для больших и сложных систем, где необходимо обеспечить гибкость изменений и независимость компонентов. Например, нужно обеспечить скорость разработки и работу 5 и более команд одновременно над разными независимыми частями проекта.
✅ При высоких требованиях к масштабируемости: микросервисы могут масштабироваться независимо, что позволяет оптимизировать ресурсы на серверах и управлять нагрузкой на сервера эффективнее.
✅ В динамичных и инновационных проектах, где частые изменения и эксперименты с новыми технологиями являются нормой.
Для начинающих свой жизненный путь проектов и стартапов, когда мало пользователей, микросервисная архитектура не рекомендуется из-за своей сложности. Лучше брать монолитный подход и стартовать с ним. Так проще, дешевле и надежнее.
Поэтому задача “переехать с монолита на микросервисы или сервисы” встречается гораздо чаще в реальном мире, чем задача “спроектировать микросервисную архитектуру для нового проекта”.
#АрхитектураGA
👍9❤2👏1
Микросервисы не нужны, монолит лучше 😬
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
Ниже приведены ситуации, когда использование микросервисной архитектуры может быть неоправданным решением:
❌ Быстрый старт проекта:
Микросервисы могут замедлить процесс запуска проекта из-за необходимости разработки и поддержки более сложной инфраструктуры.
Монолитные архитектуры позволяют быстрее выйти на рынок, что особенно важно для стартапов и проектов с ограниченными сроками.
❌ Высокие требования к согласованности данных:
Микросервисы часто используют паттерн "база данных на сервис", что может усложнить согласованность данных между различными сервисами.
Для проектов, требующих высокой согласованности данных, микросервисы могут не подойти.
❌ Тесная связанность компонентов:
Если функциональные компоненты приложения тесно связаны и не могут быть легко изолированы, переход на микросервисы потребует значительной переработки кода и архитектуры.
Актуально не только для задач на переезд, но и для этапа проектирования новых систем.
❌ Сложности отладки и мониторинга:
В микросервисных архитектурах отладка и мониторинг могут быть затруднены, поскольку проблемы могут распространяться по множеству сервисов и зависеть от их взаимодействия.
❌ Сложность организации инфраструктуры и процесса разработки:
Разработка и создание инфраструктуры для микросервисов требует значительных усилий и ресурсов на начальном этапе, что может быть неоправданно для небольших проектов или проектов, где скорость выхода на рынок критична.
❌ Необходимость в высокой квалификации разработчиков и системных аналитиков:
Микросервисы требуют от команды разработчиков высокого уровня квалификации и понимания распределенных систем, что может быть проблематично для небольших команд или стартапов.
Важно помнить, что микросервисы — это инструмент, а не цель. Перед переходом на микросервисную архитектуру необходимо провести тщательный анализ, учитывая специфику проекта, цели бизнеса и имеющиеся ресурсы.
Мартин Фаулер, один из основоположников идеи микросервисов, предлагает подход "Сначала — монолит" (MonolithFirst). Этот подход предполагает начало работы в монолитной архитектуре, и последующий постепенный переход на микросервисы, когда это станет необходимо: при достижении определенного уровня сложности и размера проекта.
Так что задача перехода с монолита на микросервисы еще долго будет оставаться актуальной 🙂
#АрхитектураGA
👍13❤2🔥2👏1
GetAnalyst_Архитектура_5_основных_сервисов_и_микросервисов.pdf
1.4 MB
🌐 5 основных сервисов и микросервисов, о которых нужно знать 🌐
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
В большинстве проектов, которые используют подход сервисной и микросервисной архитектуры, можно встретить эти пять основных сервисов.
Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с архитектурой.
❤️ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.
Пользователи отправляют свои учетные данные (логин и пароль) в микросервис аутентификации. Микросервис взаимодействует с БД пользователей для проверки учетных данных и, если необходимо, генерирует токены доступа (например, JWT). После успешной аутентификации микросервис возвращает токен для пользователя. Токен проверяется на каждом запросе к защищенным ресурсам.
❤️ Управление пользователями
Обработка регистраций, управление профилями пользователей, хранение и обработка данных пользователей. Взаимодействует с сервисом аутентификации для создания учетных записей и управления ими.
❤️ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).
Получает запросы на отправку уведомлений от других сервисов. Обеспечивает интеграцию с внешними поставщиками услуг для отправки email, SMS и push-уведомлений, управляет очередями сообщений и шаблонами уведомлений.
❤️ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация структуры и хранения контента. Взаимодействует с базами данных и файловыми хранилищами.
❤️ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.
Обоснование для выделения сервисов и их назначение более подробно описаны в прикрепленной мини-книге.
Пересылайте пост в ЛС и сохраняйте в избранное, чтобы не потерять ❤️
#АрхитектураGA
👍26❤🔥8🔥3❤2⚡1👏1
⚡ Виды API для взаимодействия компонентов системы ⚡
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
Pinterest
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом. Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Другими словами, если для взаимодействия пользователя и программы как правило используется пользовательский интерфейс (UI - User Interface), то для взаимодействия программы с другой программой используется программный интерфейс (API - Application Programming Interface) 🧈
Основные виды API:
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
В деталях 👇
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепциях ресурсов и методов (GET, POST, PUT, PATCH, DELETE и другие).
Широко используется для веб-, мобильных приложений и микросервисной архитектуры.
Пример документации:
Wildberries
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает сложные операции и стандарты безопасности.
Считается, что в основном применяется в корпоративных системах, требующих высокого уровня надежности и безопасности. Устаревает. Современные средства безопасности на уровне инфраструктуры делают REST более приятным и менее тяжеловесным в использованию по сравнению с SOAP.
Пример документации:
PayPal (обратите внимание, что устаревший)
Самые интересные API с примерами документации чуть позже 😉👇
#АрхитектураGA
🔥24👍5❤4👏1🤩1
⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Contentful
⚡ gRPC
Использует Protocol Buffers для сериализации данных и поддерживает как синхронные, так и асинхронные вызовы.
Эффективен для микросервисной архитектуры с высокими требованиями к производительности. Очень много коллег, кто в новых проектах на микросервисной архитектуре его использует сразу, даже не рассматривая REST.
Пример документации:
Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется для приложений, требующих мгновенного обмена данными, например, чаты или системы оповещений.
Пример документации:
Binance Биржа
Для системного аналитика важно понимать, когда и в каких случаях используются определенные виды API, чтобы точно описывать требования к различным интеграциям и понимать, с помощью каких технологий можно реализовывать различные сценарии работы системы.
#АрхитектураGA
👍8❤4❤🔥1👏1💯1
😱 Я боюсь публичных выступлений 😥
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
Немного о моем пути в изучении английского...
Да, я говорю по-английски. Свободно, быстро. Меня понимают, но я слышу ошибки в своей речи, слышу акцент. И. Неожиданно. У меня страх публичных выступлений на английском. С ним я борюсь уже не первый год.
Два последних года я пыталась самостоятельно преодолеть этот барьер, но максимум, который я достигла - в работе с клиентами и в разговорах один на один я чувствую себя уверенно и не теряюсь. А вот на публику презентации делать боюсь.
Впервые, чуть больше 5 лет назад, я серьезно занялась английским, так как мне надо было учиться в США. Тогда я просто каждый день учила новые слова, читала, смотрела новости и работала с преподавателями, чтобы меня двигали вперед и направляли в обучении. С педагогами база и задания, далее самостоятельная отработка и проверка.
Это продвинуло мой английский с уровня "Hello, my name is Katya" и отсутствия понимания собеседников, до сложных душевных и бизнесовых диалогов.
Пришел час X. Сейчас мне нужно выступать на английском. И одна я себя с места не сдвину. Поэтому теперь у меня еще минус 3 часа в неделю на дополнительное обучение. Я уверена в своих силах, я знаю, что могу достичь идеала, но мне нужен тот самый прорыв, который, кажется, мне не под силу сделать без наставника.
Сейчас я ищу митапы и конференции, на которых смогу позориться, как мне кажется. Это большой шаг для меня, страшно, но мне нужны эти изменения.
Иногда, чтобы действительно двигаться вперед, нужно признать, что даже самым упорным из нас может понадобиться чья-то помощь. Верю, что к первому дедлайну должна стать лучшей версией англоговорящей себя.
Пожелайте удачи! 🦄🙏❤️
❤61🔥21👏13👍6❤🔥3⚡2
С днём рождения, GetAnalyst 🎊🎉🥳
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
18 мая 2021 года - официальная дата запуска проекта. Купили домен. Сделали первую версию синего сайта. Я отправилась на конференцию собирать первых аналитиков в сообщество на 0 участников. А на этой неделе нас перевалило за 8 тысяч человек.
В прошлом году я рассказывала через что прошла, чтобы сделать GetAnalyst. Трудоголизм, дисциплина и желание делиться опытом.
Бывает всякое. За кулисами есть разные дни)) Много непрерывных улучшений. Каждую неделю десятки новых постов, до 5 презентаций по обучению проходят преобразование или разработку. Много задач. Но я дисциплинированный трудоголик, который любит своё дело. С одной работы на вторую, но я вижу результаты. Это важно.
В этом году на позитиве расскажу, что сделано с 18 мая 2023 нашей командой:
1. Запустили подкаст.
2. Развиваем YouTube-канал.
3. Запустили программу Архитектура - самый топ для системных аналитиков.
4. Запустили уникальные практикумы по БД на продвинутые темы.
5. Одна голова - хорошо, а больше опытных в узких темах экспертов - лучше. Улучшаем всё что возможно и дополняем новым опытом.
6. Редизайн всего. Мелочь, а приятно.
7. Сайт почти на 100% обновили. Платформа получилась)) Обратите внимание на блог и подкасты, если еще там не были.
8. Почти 400 аналитиков выросли с нами за год.
(9. Благодаря GetAnalyst и приобретенной публичности, мне удалось получить продвинутое членство в международных ассоциациях, признание Young Professional, рекомендации и благодарственные письма от крупных компаний 🙏)
Спасибо вам, что рекомендуете сообщество своим коллегам и начинающим аналитикам. Делитесь полезными материалами из канала, приходите на открытые вебинары и остаётесь с нами.
Благодаря вам GetAnalyst продолжает становиться лучше.
GetAnalyst - это не Катя Ананьева. GetAnalyst - это вы ❤️
С тремя годиками. Расти большой 🚀
Happy Birthday! 🥳
С любовью,
Екатерина Ананьева
и команда GetAnalyst.
❤67🍾40❤🔥11🔥11👏5🎉5👍3
⚡ API как часть архитектурного проектирования ⚡
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
Взаимодействие приложений в системе через API - одно из ключевых архитектурных решений, особенно в сервисной и микросервисной архитектуре.
При разработке схемы архитектуры в С4 необходимо указывать технологии для каждого элемента системы (сервиса, микросервиса, приложения), а также виды API, обеспечивающие взаимодействие этих элементов.
Это справедливо не только для C4. В любой упрощенной схеме архитектуры следует делать то же самое.
🟢 API и правила их выбора определяют на этапе проектирования архитектуры.
Интересный факт:
Для одного сервиса может быть два или даже три вида API, которые он предоставляет своим клиентам. Всё зависит от бизнес-логики и назначения сервиса. Это отражается на схеме и в архитектурной документации.
Касательно нотации моделирования архитектуры C4, которую мы разбираем на примере проекта TelMed, API отображаются на следующих уровнях:
⚪️ Контекстная диаграмма (Context Diagram):
Показывать виды API не обязательно, но полезно указать, через какие API происходит взаимодействие с внешними системами.
⚪️ Диаграмма контейнеров (Container Diagram):
API могут быть отображены как интерфейсы между приложениями, сервисами и внешними системами.
⚪️ Диаграмма компонентов (Component Diagram):
Показывает API, которые реализуются внутри контейнера - приложения, сервиса или микросервиса, чтобы к ним могли обращаться другие системы и сервисы. Также показывает API к внешним системам, если есть интеграции.
⚪️ Диаграмму кода мы не рассматриваем, так как она не актуальна для аналитиков.
Обратите внимание, что на схемах для каждого вида API также указываются протоколы и форматы сообщений, с которыми они работают, например, HTTP/JSON.
Знание основных видов API, принципов их работы, примеров использования и умение проверять их работу, помогают системным аналитикам (с архитекторами и разработчиками) приземлить отдельные бизнес- и нефункциональные требования на конкретные технологии.
Примеры схем С4 с API:
+ Шаблон C4 в Miro
+ Статья по C4
#АрхитектураGA
❤7👍5🔥1💯1
💥 Сервисная архитектура с нуля для проекта TelMed 💥
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
Мы познакомились с теорией по сервис-ориентированному и микросервисному подходам к проектированию архитектуры, понимаем отличия от монолитов.
Пришло время разобраться на практике, как может выглядеть архитектура проекта TelMed.
Хочу сразу отметить, что буду использовать смешанный подход: чистых микросервисов или чистого SOA не будет. Это смесь, как в реальной жизни. Теория-теорией, но в реальности она другая. Поэтому в заголовке поста название "сервисная", как нечто более общее.
Для выделения списка сервисов воспользуюсь чек-листом из предыдущего поста и знанием бизнес-контекстов проекта (очень помогает!).
Сервисы и микросервисы TelMed:
1. Аутентификация и авторизация
2. Управление пользователями
3. Уведомления и рассылки
4. Личный кабинет пациента
Регистрация пациентов, хранение персональных данных, медицинской карты и медицинской истории.
5. Запись на прием
Поиск врачей, планирование и отслеживание консультаций, уведомление пациентов.
6. Учет оборудования
Управление заказом и доставкой медицинского оборудования.
7. Онлайн-консультации
Обеспечение защищенной видеосвязи, чат и обмен документами.
8. Аптечные услуги
Создание электронных рецептов, мониторинг наличия лекарств, управление доставкой.
9. Анализы
Выдача направлений на анализы, автоматическое получение результатов.
10. Платежи
Обработка и учет платежей, интеграция с платежными системами.
11. Личный кабинет врача
Управление профилем врача и настройка доступного времени для консультаций.
Для отображения архитектуры я буду использовать нотацию C4 / Container.
В каком инструменте сделать пример сервисной архитектуры, чтобы вы могли забрать себе исходник?
1. Miro - пример будет как тут 👍
2. Structurizr - через код, доп. примеры по нему тут ❤️
3. Draw.io 🔥
Голосуйте реакцией 👍❤️🔥
#АрхитектураGA #TelMedGA
🔥47👍15❤13
Ищу эксперта в REST API, Postman и Swagger, готового учиться публично выступать 👀
Если ты эксперт, то подробности и Google-форма тут 🤝
Если ты эксперт, то подробности и Google-форма тут 🤝
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
🙌 Новый эпизод подкаста GetAnalyst про Нефункциональные требования 🙌
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
В этом эпизоде мы обсуждаем нефункциональные требования: не только в теории, но и на практике. Приводятся конкретные примеры для каждого вида таких требований, которые могут быть применены в реальных ИТ-проектах.
Этот выпуск поможет системным и бизнес-аналитикам при подготовке к собеседованиям или перед стартом работы над нефункциональными требованиями для ТЗ нового проекта.
1:08 - Когда мы встречаемся с нефункциональными требованиями и что важно знать о них перед началом работы. Знакомство с проектом TelMed (https://t.me/getanalysts/1646).
08:09 - Что такое нефункциональные требования (НФТ). О проверяемости нефункциональных требований.
12:28 - Определение нефункциональных требований по Вигерсу (книга “Разработка требований к программному обеспечению”), ГОСТ-34 и Software Requirements Specification, IEEE.
23:21 - Источники нефункциональных требований.
29:54 - Виды нефункциональных требований на примере медицинского проекта TelMed. Этап сбора потребностей из источников - первичная аналитика.
45:04 - Работа с нефункциональными требованиями для ТЗ и рядовых постановок задач на разработчиков. Личный опыт. Связь с принципами дизайна UI и архитектурой.
51:06 - Доступность. SLA - service-level agreement. Удобство установки.
01:01:36 - Целостность данных. Совместимость. Производительность.
01:06:24 - Надежность. Устойчивость. Защита и безопасность.
1:13:00 - Удобство использования. О боли про “Интуитивно понятный интерфейс”.
1:16:10 - Эффективность использования ресурсов.
1:18:10 - Модификация. Переносимость. Возможность повторного использования.
1:21:41 - Масштабируемость.
1:24:03 - Проверяемость и тестируемость. Другие требования по ГОСТ-34.
1:27:28 - Порядок работы с нефункциональными требованиями.
1:34:54 - Заключение и рекомендации.
📚 Статья к подкасту
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify
Делитесь с коллегами и подписывайтесь на всех площадках! 😉
🔥19❤5❤🔥2👍2🦄2⚡1
😕 Завышение сложности архитектуры (овер-инжиниринг): создание избыточно сложной архитектуры в проектах, где в этом нет необходимости 😕
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
🔗 Ошибки в проектировании архитектуры: на что обращать внимание
#АрхитектураGA
Завышение сложности архитектуры случается, когда для системы создают слишком сложную систему, не всегда нужную для обеспечения её работы.
Это может включать использование избыточного количества технологий, паттернов проектирования или большого количества компонентов для реализации, усложняющих понимание, разработку, тестирование и поддержку системы.
◽ Пример:
Разработка системы интернет-магазина для малого бизнеса, который продает всего несколько видов товаров. Вместо использования простой монолитной архитектуры или шаблонного "интернет-магазина из коробки", команда решила реализовать собственную систему на основе микросервисов, разделив каждую функцию (обработку заказов, управление каталогом товаров, обработку платежей) на отдельные сервисы.
Это значительно увеличило сложность проекта, требуя дополнительных ресурсов для разработки, координации между сервисами и обеспечения их надежной работы. В результате, затраты на разработку и поддержку системы оказались гораздо выше, чем если бы была выбрана более простая архитектура, адекватная масштабам и потребностям бизнеса.
Почему происходит:
🔻 Переоценка требований.
🔻 Стремление к совершенству
🔻 Недостаточный опыт
Рекомендации:
✅ Стремитесь к простоте в проектировании, избегая ненужной сложности в целом. Идеальная архитектура простая и понятная.
✅ Не учитывайте функциональность до тех пор, пока она действительно не потребуется.
✅ Держите баланс между долгосрочным планированием и текущими потенциальными усложнениями.
✅ Используйте принцип итеративной разработки. Разрабатывайте функции в системе поэтапно, добавляя сложность только тогда, когда это оправдано.
✅ Регулярно пересматривайте архитектуру на возможность упрощения и улучшения.
Какие еще ошибки встречаются в проектировании архитектуры? 🧐
Подробности и ответ в статье:
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍7🔥1
🔔 Завершаем предзапись на архитектуру сегодня в 23:59 Мск🔔
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
Подробнее об условиях предзаписи можно почитать здесь и в программе на сайте.
Старт предобучения 28 мая 2024
Подробности о программе и запись
А пока мы продолжаем рассказывать о программе словами коллег-аналитиков, которые буквально вчера завершили обучение на первом потоке 🙌 🎉🥳
Решила пойти не думая, т.к. предыдущие курсы, которые прошла, очень понравились
подачей, объемом информации и, самое главное, качественной объемной практикой с ДЗ и качественной проверкой ДЗ.
Задания не абстрактные, а конкретные, жизненные, привязанные к системам, которыми мы пользуемся ежедневно. Выполняя задание, мы можем сразу увидеть как это все работает уже со стороны не только пользователя, но и аналитика.
Было очень интересно познавать, как это работает с точки зрения архитектуры, микросервисов и БД. Хочу отметить, что проверка ДЗ ведется глубоко и индивидуально, "не для галочки".
Больше обратной связи будем постепенно добавлять на сайт 💛
Если честно, то нам тоже надо оставлять публичную обратную связь на тех, кто у нас учится. Я и все эксперты, кто работал с группой "Архитектура" (и не только), разными словами делимся друг с другом впечатлениями о том, насколько осознанная группа и насколько круто было работать.
Команда аналитиков с нами не для галочки "я на обучении", все работают на результат 💪💎🤝 Спасибо вам за это!
Уже работаем над улучшениями и готовимся ко встрече с новой командой "Архитектура"!
👍6❤3👌1
✅ Шаблон Draw.Io для C4 - примеры для проекта TelMed ✅
Собрала Draw.Io с примером для проекта TelMed и структурировала информацию для вас.
1. Страница "Элементы C4"
На ней вы найдете сгруппированные элементы, которые могут присутствовать на каждом из уровней C4, которые реально используются в проектах (Context, Container, Component).
Также мини-инструкция, как включить эти элементы в Draw.Io в левой панели.
2. Страница "С4 - Проект TelMed от GetAnalyst"
На ней вы найдете:
+ Проект TelMed - C4 / Context (пояснения тут)
+ Проект TelMed - C4 / Container для монолитной архитектуры (пояснения тут)
+ Проект TelMed - C4 / Container для смешанной архитектуры - сервисная + микросервисная (пояснения тут)
📌 Файл Draw.Io для просмотра в онлайн:
https://app.diagrams.net/#G1nk3D0XqRQ9A-2Bw9yGlLY2ZOOutSEStR#%7B%22pageId%22%3A%22qvlD7eRmiriUJArze8cl%22%7D
Для просмотра потребуется авторизация на Google Диске.
Как забрать себе и использовать:
📌 Файл Draw.Io, который вы можете сохранить себе, доступен по этой ссылке
1. Перейти по ссылке.
2. Сверху будет иконка "Скачать"
3. После скачивания:
3.1. Загружаете на свой гугл-диск и открываете с помощью приложения draw io.
3.2. Открываете на десктопном (установленном на компьютер) draw io.
Теперь вы можете самостоятельно создавать C4 и подглядывать на пример, который сделан согласно нотации на 100%.
#АрхитектураGA #TelMedGA
Собрала Draw.Io с примером для проекта TelMed и структурировала информацию для вас.
1. Страница "Элементы C4"
На ней вы найдете сгруппированные элементы, которые могут присутствовать на каждом из уровней C4, которые реально используются в проектах (Context, Container, Component).
Также мини-инструкция, как включить эти элементы в Draw.Io в левой панели.
2. Страница "С4 - Проект TelMed от GetAnalyst"
На ней вы найдете:
+ Проект TelMed - C4 / Context (пояснения тут)
+ Проект TelMed - C4 / Container для монолитной архитектуры (пояснения тут)
+ Проект TelMed - C4 / Container для смешанной архитектуры - сервисная + микросервисная (пояснения тут)
📌 Файл Draw.Io для просмотра в онлайн:
https://app.diagrams.net/#G1nk3D0XqRQ9A-2Bw9yGlLY2ZOOutSEStR#%7B%22pageId%22%3A%22qvlD7eRmiriUJArze8cl%22%7D
Для просмотра потребуется авторизация на Google Диске.
Как забрать себе и использовать:
📌 Файл Draw.Io, который вы можете сохранить себе, доступен по этой ссылке
1. Перейти по ссылке.
2. Сверху будет иконка "Скачать"
3. После скачивания:
3.1. Загружаете на свой гугл-диск и открываете с помощью приложения draw io.
3.2. Открываете на десктопном (установленном на компьютер) draw io.
Теперь вы можете самостоятельно создавать C4 и подглядывать на пример, который сделан согласно нотации на 100%.
#АрхитектураGA #TelMedGA
🔥28👍11❤6😍5
🔥 Онлайн-практика по Архитектуре систем 29 мая 🔥
Обсуждения Backend-разработчиков могут вызывать страх и желание уточнять каждое слово через Google: "Выделяем микросервис, делаем API-Gateway, тут оркестратор не нужен, здесь берём REST API, а GraphQL не подойдёт, а там возможно gRPC".
Так, стооп, а почему? Нет времени объяснять.
Но запроектировать интеграцию внутри системы и описать метод gRPC уже просят.
И вот ты в шоке. С заметками по встрече. И начинаются приключения с поиском информации.
Чтобы понять тему и перенести знания в реальный проект, нужны большие и реалистичные примеры, а не "три квадратика, две стрелочки - смотри как просто" 😠
Поэтому мы готовим для вас практический вебинар с жизненным примером, чтобы разобраться с новой темой:
🔥 Архитектура и API: от монолита к микросервисам
🗓 29 МАЯ, 19:00 МСК (СРЕДА)
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Отработанные на реальной задаче навыки по архитектуре и API помогут перейти на новый уровень в системном анализе и стать более ценным специалистом для вашей компании 🙌
Готовы получать новые навыки сразу на практике?
Регистрируйтесь и делитесь постом с коллегами! 😉
Обсуждения Backend-разработчиков могут вызывать страх и желание уточнять каждое слово через Google: "Выделяем микросервис, делаем API-Gateway, тут оркестратор не нужен, здесь берём REST API, а GraphQL не подойдёт, а там возможно gRPC".
Так, стооп, а почему? Нет времени объяснять.
Но запроектировать интеграцию внутри системы и описать метод gRPC уже просят.
И вот ты в шоке. С заметками по встрече. И начинаются приключения с поиском информации.
Чтобы понять тему и перенести знания в реальный проект, нужны большие и реалистичные примеры, а не "три квадратика, две стрелочки - смотри как просто" 😠
Поэтому мы готовим для вас практический вебинар с жизненным примером, чтобы разобраться с новой темой:
🔥 Архитектура и API: от монолита к микросервисам
🔗 ЗАРЕГИСТРИРОВАТЬСЯ
Отработанные на реальной задаче навыки по архитектуре и API помогут перейти на новый уровень в системном анализе и стать более ценным специалистом для вашей компании 🙌
Готовы получать новые навыки сразу на практике?
Регистрируйтесь и делитесь постом с коллегами! 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍7❤2
💫 Как быстро разобраться с новым API: REST, SOAP, GraphQL, и другие 💫
Работа с неизвестными API так или иначе встречается в нашей работе, когда мы растем: расширяем опыт и экспертизу. С потребностью изучения API аналитики встречаются в ситуациях, когда делают интеграции с новыми системами, проектируют архитектуру и выбирают API для межсервисного взаимодействия с архитекторами, при переходе в новые компании и проекты.
Мои первые API, с которыми я начинала работать, были REST и SOAP. Сначала я знакомилась с ними в интеграциях, потом при проектировании методов и постановке задач на Backend-разработчиков.
Больше всего опыта у меня связано с REST и он основа моих знаний. одновременно с ним был SOAP, но в меньших объемах. Когда появилась потребность узнать WebSocket, я уже интуитивно понимала, что важно искать в API-документации и куда смотреть, чтобы разобраться.
Выработался алгоритм “как в знакомиться с новым способом обмена данными между системами”. Так что GraphQL, SDK и прочие страшные на первый взгляд названия уже не были страшны.
Как я вижу - изучение API сравнимо с изучением иностранных языков. С детства ты учишь и используешь один язык (для меня это был REST API), в школе тебя заставляют учить второй язык и он дается тяжело. Из любопытства учишь 3-ий, и начинаешь понимать особенности “как учить”. А с 4-ого тебе всё легко 🙃
Делюсь своим подходом к изучению API с вами 💫
-------------
С чего начать изучение нового API?
1️⃣ Узнать общую информацию
2️⃣ Принцип формирования URL запроса
3️⃣ Принцип формирования Body запроса
4️⃣ Принцип формирования ответа (коды + тело)
5️⃣ Требования к авторизации и аутентификации запросов
6️⃣ Примеры документации
7️⃣ Тестирование через Postman или другие инструменты
🎱 Всё остальное познается через практику и опыт работы над проектами.
-------------
Подробнее каждый пункт разберу в следующем посте 👇
#АрхитектураGA
Работа с неизвестными API так или иначе встречается в нашей работе, когда мы растем: расширяем опыт и экспертизу. С потребностью изучения API аналитики встречаются в ситуациях, когда делают интеграции с новыми системами, проектируют архитектуру и выбирают API для межсервисного взаимодействия с архитекторами, при переходе в новые компании и проекты.
Мои первые API, с которыми я начинала работать, были REST и SOAP. Сначала я знакомилась с ними в интеграциях, потом при проектировании методов и постановке задач на Backend-разработчиков.
Больше всего опыта у меня связано с REST и он основа моих знаний. одновременно с ним был SOAP, но в меньших объемах. Когда появилась потребность узнать WebSocket, я уже интуитивно понимала, что важно искать в API-документации и куда смотреть, чтобы разобраться.
Выработался алгоритм “как в знакомиться с новым способом обмена данными между системами”. Так что GraphQL, SDK и прочие страшные на первый взгляд названия уже не были страшны.
Как я вижу - изучение API сравнимо с изучением иностранных языков. С детства ты учишь и используешь один язык (для меня это был REST API), в школе тебя заставляют учить второй язык и он дается тяжело. Из любопытства учишь 3-ий, и начинаешь понимать особенности “как учить”. А с 4-ого тебе всё легко 🙃
Делюсь своим подходом к изучению API с вами 💫
-------------
С чего начать изучение нового API?
1️⃣ Узнать общую информацию
2️⃣ Принцип формирования URL запроса
3️⃣ Принцип формирования Body запроса
4️⃣ Принцип формирования ответа (коды + тело)
5️⃣ Требования к авторизации и аутентификации запросов
6️⃣ Примеры документации
7️⃣ Тестирование через Postman или другие инструменты
🎱 Всё остальное познается через практику и опыт работы над проектами.
-------------
Подробнее каждый пункт разберу в следующем посте 👇
#АрхитектураGA
👍34❤7🔥4👎2
💫 Пошаговый план: с чего начать изучение нового API? 💫
1️⃣ Узнать общую информацию
Найдите статьи в сети, где рассказывают об использовании:
+ назначение,
+ общие принципы,
+ особенности и отличия от других API,
+ примеры использования в разных системах,
+ для каких видов архитектуры подходит,
+ влияние на выполнение нефункциональных требований проекта (НФТ).
2️⃣ Принцип формирования URL запроса
Есть ли типы методов, по аналогии с REST: POST, GET, PUT и другие.
Принцип формирования адреса запроса: структура и нейминг (именование).
3️⃣ Принцип формирования Body запроса
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
4️⃣ Принцип формирования ответа (коды + тело)
+ Используемые стандартизованные коды ошибок (по аналогии со стандартными кодами HTTP-200, HTTP-404 и др).
+ Возможность и рекомендации для использования внутренних кодов ошибок.
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
5️⃣ Требования к авторизации и аутентификации запросов
+ Какие способы авторизации используются.
+ Как она настраивается для запросов.
+ Как авторизационные данные хранятся на сервере для всей системы или для отдельных пользователей.
6️⃣ Примеры документации
+ Ищу примеры API-документации, которую можно протестировать.
+ Примеры документации, которая легко и понятно читается, чтобы использовать за образец на будущее при постановке задач на бэкенд разработчиков.
+ Также примеры документации, оформленной через разные инструменты (например, Swagger).
7️⃣ Тестирование через Postman или другие инструменты
+ Сначала определяю список инструментов, через которые можно проверять методы API (Postman, Swagger, Insomnia и другие).
+ Потом список инструментов, через которые можно документировать методы API (Confluence не считается).
+ Затем тестирую API и создаю коллекции запросов, создаю примеры документации, которые потенциально отправляются в моё портфолио.
🎱 Всё остальное познается через практику и опыт работы над проектами.
Этот подход точно применим для REST, SOAP, WebSocket, gRPC, GraphQL.
Рекомендую использовать его в самостоятельном обучении. Также с его помощью передаю свой опыт коллегам, которые приходят на проекты GetAnalyst 💫
Делитесь с коллегами и сохраняйте в закладки ❤️
#АрхитектураGA
1️⃣ Узнать общую информацию
Найдите статьи в сети, где рассказывают об использовании:
+ назначение,
+ общие принципы,
+ особенности и отличия от других API,
+ примеры использования в разных системах,
+ для каких видов архитектуры подходит,
+ влияние на выполнение нефункциональных требований проекта (НФТ).
2️⃣ Принцип формирования URL запроса
Есть ли типы методов, по аналогии с REST: POST, GET, PUT и другие.
Принцип формирования адреса запроса: структура и нейминг (именование).
3️⃣ Принцип формирования Body запроса
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
4️⃣ Принцип формирования ответа (коды + тело)
+ Используемые стандартизованные коды ошибок (по аналогии со стандартными кодами HTTP-200, HTTP-404 и др).
+ Возможность и рекомендации для использования внутренних кодов ошибок.
+ Используемый формат сообщений (JSON / XML и другие).
+ Особенности работы с этим форматом сообщений: структура, нейминг параметров, работа с массивами и уровнями вложенности.
5️⃣ Требования к авторизации и аутентификации запросов
+ Какие способы авторизации используются.
+ Как она настраивается для запросов.
+ Как авторизационные данные хранятся на сервере для всей системы или для отдельных пользователей.
6️⃣ Примеры документации
+ Ищу примеры API-документации, которую можно протестировать.
+ Примеры документации, которая легко и понятно читается, чтобы использовать за образец на будущее при постановке задач на бэкенд разработчиков.
+ Также примеры документации, оформленной через разные инструменты (например, Swagger).
7️⃣ Тестирование через Postman или другие инструменты
+ Сначала определяю список инструментов, через которые можно проверять методы API (Postman, Swagger, Insomnia и другие).
+ Потом список инструментов, через которые можно документировать методы API (Confluence не считается).
+ Затем тестирую API и создаю коллекции запросов, создаю примеры документации, которые потенциально отправляются в моё портфолио.
🎱 Всё остальное познается через практику и опыт работы над проектами.
Этот подход точно применим для REST, SOAP, WebSocket, gRPC, GraphQL.
Рекомендую использовать его в самостоятельном обучении. Также с его помощью передаю свой опыт коллегам, которые приходят на проекты GetAnalyst 💫
Делитесь с коллегами и сохраняйте в закладки ❤️
#АрхитектураGA
❤🔥20👍14💯4❤1