🛠 Монолитная архитектура: погружение в детали 🛠
Монолитная архитектура – это подход к разработке программного обеспечения, при котором все компоненты приложения объединены в единый и неделимый блок, называемый монолитом.
Можно выделить две основные группы монолитов:
👉 Классический (жесткий) монолит: весь код Frontend и Backend в одном месте.
👉 Современный монолит: код UI (Frontend) выделяют в отдельную кодовую базу, но при этом проект может всё еще остаётся монолитным в части сервера (Backend).
Подробнее рассказала в картинках к посту 📚
#АрхитектураGA
Монолитная архитектура – это подход к разработке программного обеспечения, при котором все компоненты приложения объединены в единый и неделимый блок, называемый монолитом.
Можно выделить две основные группы монолитов:
👉 Классический (жесткий) монолит: весь код Frontend и Backend в одном месте.
👉 Современный монолит: код UI (Frontend) выделяют в отдельную кодовую базу, но при этом проект может всё еще остаётся монолитным в части сервера (Backend).
Подробнее рассказала в картинках к посту 📚
#АрхитектураGA
👍35❤7🤩1😍1
🪲 Проблемы монолита: разбор на примерах 🪲
🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности (ресурсы): память, ядра процессора и другие.
> Добавляем интеграцию с новой системой, которая расширяет функциональность приложения - из-за новых функций может вырасти количество ресурсов, используемых на сервере.
> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям, чтобы выдержать нагрузку.
В архитектуре с сервисами добавить копии можно было бы только на основной сервис, который будут “атаковать” пользователи в ходе рекламной кампании.
🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных реалиях. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
> В существующем API-методе, в платежной части системы, нужно добавить к JSON-ответу дополнительное поле. Маленькая задача.
В условиях монолита, чтобы выпустить обновление на прод, придётся обновить весь сервер. На время обновления он может быть недоступен.
В условиях сервисов обновить надо только небольшой сервис платежей, который реализует этот API метод. Такое точечное обновление не будет блокировать другие важные функции системы в архитектуре с сервисами.
🔺3. Сложность масштабирования команды
Приходя в проект, аналитики, разработчики и тестировщики должны узнать очень много обо всех частях системы, чтобы не вредить ей при развитии и знать, как очередная маленькая функция, может задеть 100 существующих...
Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.
В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.
🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.
🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.
Высококвалифицированные специалисты редко идут в такие проекты, так как им не хочется деградировать и поддерживать легаси код (написанный на старой версии языка, с использованием устаревшего фреймворка, без документации).
Я тоже всегда избегала таких проектов, т.к. знала, что уровень команды, с которой предстоит работать, будет низкий, и я не смогу развиваться - не будет возможности пробовать новое, спрашивать коллег и расти.
Это основные проблемы монолитной архитектуры 😔
Но в ней есть и очень много плюсов:
+ легкость в разработке
+ не нужна супер-опытная команда
+ нет проблем в синхронизации данных, которые распределены по разным БД
+ легче устанавливать проект на сервере
Она идеальна для стартапов! 🚀
Монолит - это не плохо. Его можно сделать архитектурно красивым, и с ним будет интересно и приятно работать 🙌 Но всё зависит от опыта программистов, архитекторов и аналитиков, которые участвуют в разработке.
Вопрос про недостатки монолитов важно знать, если предстоит сотрудничество с архитекторами. А также он есть среди подборок теоретических вопросов для собеседований на СА.
Сохраняем этот пост в памяти, чтобы быть готовыми к развернутым ответам 🙂
#АрхитектураGA
🔺1. Масштабируемость
Добавление новых функций и рост пользователей требуют больше затрат на серверные мощности (ресурсы): память, ядра процессора и другие.
> Добавляем интеграцию с новой системой, которая расширяет функциональность приложения - из-за новых функций может вырасти количество ресурсов, используемых на сервере.
> Планируется повышение нагрузки на приложение в 2 раза из-за новой рекламной акции: надо запустить еще несколько копий ВСЕГО такого же огромного монолита, к уже работающим параллельно копиям, чтобы выдержать нагрузку.
В архитектуре с сервисами добавить копии можно было бы только на основной сервис, который будут “атаковать” пользователи в ходе рекламной кампании.
🔺2. Сложность поддержки и развертывания
Бывает, что приходится полностью останавливать работу системы в процессе обновлений. Это почти недопустимо в современных реалиях. Важно работать 24/7, чтобы обеспечивать высокий уровень сервиса.
> В существующем API-методе, в платежной части системы, нужно добавить к JSON-ответу дополнительное поле. Маленькая задача.
В условиях монолита, чтобы выпустить обновление на прод, придётся обновить весь сервер. На время обновления он может быть недоступен.
В условиях сервисов обновить надо только небольшой сервис платежей, который реализует этот API метод. Такое точечное обновление не будет блокировать другие важные функции системы в архитектуре с сервисами.
🔺3. Сложность масштабирования команды
Приходя в проект, аналитики, разработчики и тестировщики должны узнать очень много обо всех частях системы, чтобы не вредить ей при развитии и знать, как очередная маленькая функция, может задеть 100 существующих...
Для аналитиков полноценное погружение в проект может занимать от 3-х месяцев до года. И к концу испытательного срока вы все еще можете допускать ошибки проектирования и продолжать исследования дальше. Это считается нормой в монолитах.
В условиях архитектуры с сервисами аналитику часто достаточно знать только про свои сервисы и его БД, а также про API связанных сервисов внутри проекта и API внешних систем.
🔺4. Единая точка отказа
Монолит ломается целиком.
Из-за отказа в работе основной и единственной БД, возникает остановка работы всей системы. Напротив, в сервисной архитектуре, остановят работу только те сервисы, которые работают с этой БД.
🔺5. Гибкость и инновации
Затрудняется внедрение новых технологий и подходов в разработке, что делает больно разработчикам.
Высококвалифицированные специалисты редко идут в такие проекты, так как им не хочется деградировать и поддерживать легаси код (написанный на старой версии языка, с использованием устаревшего фреймворка, без документации).
Я тоже всегда избегала таких проектов, т.к. знала, что уровень команды, с которой предстоит работать, будет низкий, и я не смогу развиваться - не будет возможности пробовать новое, спрашивать коллег и расти.
Это основные проблемы монолитной архитектуры 😔
Но в ней есть и очень много плюсов:
+ легкость в разработке
+ не нужна супер-опытная команда
+ нет проблем в синхронизации данных, которые распределены по разным БД
+ легче устанавливать проект на сервере
Она идеальна для стартапов! 🚀
Монолит - это не плохо. Его можно сделать архитектурно красивым, и с ним будет интересно и приятно работать 🙌 Но всё зависит от опыта программистов, архитекторов и аналитиков, которые участвуют в разработке.
Вопрос про недостатки монолитов важно знать, если предстоит сотрудничество с архитекторами. А также он есть среди подборок теоретических вопросов для собеседований на СА.
Сохраняем этот пост в памяти, чтобы быть готовыми к развернутым ответам 🙂
#АрхитектураGA
🔥24👍11❤6🤩2
Сервис-ориентированная архитектура (SOA) представляет собой подход, который позволяет разрабатывать приложения как набор взаимосвязанных сервисов.
👉 Сервис – это маленький монолит.
👉 SOA – это набор маленьких монолитов, которые взаимодействуют друг с другом.
Когда мы думаем о серверной части приложения Backend, то в SOA надо представлять, что это НЕ одно большое приложение, как монолит, НЕ один прямоугольник “Backend” на схеме архитектуры, а много разных прямоугольников - сервисов, каждый из которых может:
+ отвечать за определенную группу функций,
+ иметь собственную БД,
+ иметь собственный API,
+ иметь собственную кодовую базу,
+ устанавливаться на отдельном сервере,
+ обновляться независимо от остальных.
👉 Эти сервисы общаются друг с другом, обычно через API или шину данных (ESB), для выполнения различных бизнес-задач.
Сервисы в SOA обычно выделяют по бизнес-контекстам или процессам, которыми они должны управлять.
В классическом примере с Интернет-магазином можно выделить сервисы:
▫️ товары,
▫️ корзина покупок,
▫️ платежи,
▫️ уведомления (sms, email, push),
▫️ ЛК пользователей.
Особенности SOA:
💪 Backend разбивается на независимые сервисы.
💪 Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы. Каждый сервис можно разрабатывать, тестировать, развертывать и масштабировать независимо.
💪 Сервисы могут масштабироваться независимо друг от друга как горизонтально, так и вертикально, что оптимизирует ресурсное использование и управление нагрузкой.
💪 Ошибки в одном сервисе обычно не влияют на работу других, что повышает надежность всей системы.
💪 SOA позволяет использовать различные технологии и языки программирования в рамках одного проекта. То есть один сервис может быть на PHP, второй на Python, а все остальные сервисы на Java. Это позволяет программистам пробовать внедрять новые технологии в проекты при разработке новых сервисов.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15❤🔥15🔥8🤩2👍1😍1
🦄 Микросервисная архитектура(MSA): погружение в детали 🦄
Микросервисная архитектура (MSA) – это эволюция сервис-ориентированной архитектуры (SOA), но более гибкая, независимая и масштабируемая.
Если монолит – это один большой блок,
а SOA – это несколько крупных сервисов,
то MSA – это сеть небольших сервисов, работающих как единая система.
Что такое микросервис (МС)?
▫️ Это небольшая, автономная служба, которая:
+ управляет данными одной сущности,
+ обслуживает строго один бизнес-процесс,
+ выполняет только одну простую функцию.
По сравнению с SOA, в MSA сервисы более узкоспециализированные и мЕньшие по размеру.
▫️ У каждого МС своя БД, API, кодовая база.
▫️ Каждый МС развернут на своём сервере, работает и релизится независимо от других.
▫️ МС не используют общую БД – каждая часть системы управляет своими данными.
👉 В МСА сервисы взаимодействуют между собой:
+ напрямую по API (REST, gRPC и другие),
+ через API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.
Набор МС для классического примера с Интернет-магазином:
🔹 Каталог товаров
🔹 Корзина
🔹 Заказы – получает данные из корзины и формирует заказ
🔹 Платежи
🔹 Управление скидками
🔹 Доставка
🔹 Уведомления (sms, email, push)
🔹 ЛК пользователей
👉 Плюсы MSA во многом совпадают с SOA:
✅ Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы
✅ Масштабируемость – можно увеличить нагрузку на конкретный сервис, не затрагивая всю систему
✅ Можно обновлять сервисы без даунтайма всей системы. А собственная БД гарантирует, что другие сервисы не будут затронуты
✅ Ошибки в одном сервисе не влияют на работу других
✅ Гибкость технологий
👉 Недостатки MSA:
❌ Сложность управления большим количеством сервисов. Мониторинг и логирование должны быть на высоком уровне, чтобы не терять сбои в отдельных частях системы
❌ Возможны задержки в работе из-за количества звеньев в цепочке обмена данными
❌ Нужна опытная команда
#АрхитектураGA
Микросервисная архитектура (MSA) – это эволюция сервис-ориентированной архитектуры (SOA), но более гибкая, независимая и масштабируемая.
Если монолит – это один большой блок,
а SOA – это несколько крупных сервисов,
то MSA – это сеть небольших сервисов, работающих как единая система.
Что такое микросервис (МС)?
▫️ Это небольшая, автономная служба, которая:
+ управляет данными одной сущности,
+ обслуживает строго один бизнес-процесс,
+ выполняет только одну простую функцию.
По сравнению с SOA, в MSA сервисы более узкоспециализированные и мЕньшие по размеру.
▫️ У каждого МС своя БД, API, кодовая база.
▫️ Каждый МС развернут на своём сервере, работает и релизится независимо от других.
▫️ МС не используют общую БД – каждая часть системы управляет своими данными.
👉 В МСА сервисы взаимодействуют между собой:
+ напрямую по API (REST, gRPC и другие),
+ через API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.
Набор МС для классического примера с Интернет-магазином:
🔹 Каталог товаров
🔹 Корзина
🔹 Заказы – получает данные из корзины и формирует заказ
🔹 Платежи
🔹 Управление скидками
🔹 Доставка
🔹 Уведомления (sms, email, push)
🔹 ЛК пользователей
👉 Плюсы MSA во многом совпадают с SOA:
✅ Сервисы можно легко добавлять или обновлять без влияния на всю систему, т.к. у них отдельные кодовые базы
✅ Масштабируемость – можно увеличить нагрузку на конкретный сервис, не затрагивая всю систему
✅ Можно обновлять сервисы без даунтайма всей системы. А собственная БД гарантирует, что другие сервисы не будут затронуты
✅ Ошибки в одном сервисе не влияют на работу других
✅ Гибкость технологий
👉 Недостатки MSA:
❌ Сложность управления большим количеством сервисов. Мониторинг и логирование должны быть на высоком уровне, чтобы не терять сбои в отдельных частях системы
❌ Возможны задержки в работе из-за количества звеньев в цепочке обмена данными
❌ Нужна опытная команда
#АрхитектураGA
❤🔥18🔥12
👉 Архитектура
◽️ Монолит:
Один большой блок - единая кодовая база Backend.
Вся логика в одном месте.
🟡 SOA:
Отдельные сервисы с независимыми кодовыми базами.
Логика распределена.
В SOA сервисы крупные и многофункциональные, их можно назвать "микромонолитами".
💚 MSA:
Небольшие, автономные сервисы, каждый из которых отвечает за управление одной сущностью, процессом или задачей.
В MSA сервисы более узкоспециализированные по сравнению с SOA.
Сравнение сервисов в SOA и MSA на примерах:
🔹 Каталог товаров
SOA:
+ Сервис "Каталог" – управляет товарами, категориями, характеристиками, поиском и рекомендациями.
MSA:
+ Сервис управления товарами – добавляет, редактирует, удаляет товары
+ Сервис поиска – отвечает только за фильтрацию, поиск и выдачу результатов
+ Сервис рекомендаций – анализирует покупки пользователей и предлагает похожие товары
🔹 Корзина покупок
SOA:
+ Сервис "Корзина" – хранит товары пользователя, управляет ценами и скидками
MSA:
+ Сервис корзины – добавляет и удаляет товары.
+ Сервис расчёта цен – отдельно высчитывает итоговую сумму с учётом акций, налогов и доставки
+ Сервис промокодов и скидок – управляет купонами, скидками, программами лояльности
------------------
👉 База данных
◽️ Монолит:
Обычно одна на всю систему, но может быть и больше.
🟡 SOA:
Сервисы могут иметь общую БД или отдельные схемы внутри одной БД.
💚 MSA:
У каждого микросервиса своя БД.
Сравнение SOA и MSA:
Например, обновление платежного модуля в интернет-магазине с MSA не затронет каталог товаров, так как у них разные БД. В то время как в SOA архитектуре могут быть проблемы с обновлениями из-за наличия общей БД.
------------------
👉 Независимость, масштабируемость и отказоустойчивость
◽️ Монолит:
Если отказывает что-то в монолите, то он ломается целиком.
Релиз обновлений приводит к полной недоступности всего Backend.
Сложно масштабировать:
- постоянно надо добавлять новые мощности (память, ядра и другие) к существующему серверу при добавлении новых функций,
- если запущено несколько параллельно работающих копий монолита, то при росте пользователя, надо запускать новую дорогую копию.
🟡 SOA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса. Но могут быть сложности с отключением нескольких сервисов, когда выполняются обновления общих БД.
Можно масштабировать каждую БД и сервис по мере необходимости - т.е. если растет нагрузка на каталог товаров, то запустим больше копий только этого сервиса, а не всей системы.
💚 MSA:
Если отказывает что-то в одном сервисе, то ломается только он, а остальная часть системы работает.
Релиз обновлений приводит к недоступности только одного сервиса, за счет собственной БД сложностей нет.
Можно масштабировать каждую БД и сервис по мере необходимости, как в SOA.
------------------
👉 Взаимодействие
◽️ Монолит:
+ внутреннее, через вызов процедур и функций в одном коде.
🟡💚 SOA и MSA:
+ напрямую по API (REST, gRPC и другие),
+ через шину данных ESB,
+ через API-сервисы, в том числе можно использовать API Gateway,
+ через оркестратор,
+ асинхронно, через брокеры сообщений как Kafka или RabbitMQ.
------------------
Когда лучше монолит, когда SOA, а когда MSA?
Когда монолит?
✅ Если у вас стартап и ограниченный бюджет.
✅ Нет опытных специалистов и архитекторов, кто работал с MSA.
✅ Нужно сделать быстро и протестировать гипотезу.
✅ Нет высокой нагрузки – мало пользователей.
Когда SOA?
✅ Большая корпоративная система с интеграциями.
✅ Если в компании уже используется ESB.
✅ Не требуется высокая скорость изменений – SOA сложнее менять, так как сервисы могут зависеть от общей БД или централизованных решений.
Когда MSA?
✅ Нужна высокая скорость изменений и независимость команд.
✅ Нагрузка на отдельные функции распределена неравномерно – например, поиск товаров требует больше вычислительных мощностей, чем расчёт скидок.
✅ Отказоустойчивость критически важна.
✅ Частые релизы.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20❤15🔥4🥰1😁1
📄 Про собеседования, резюме и вилки ЗП 📄
Проходить собеседования - тоже навык, и его надо оттачивать.
Но эту тему я почти не поднимаю в канале, так как я больше "суровый технарь", который передаёт технические навыки и опыт работы 😁
А чтобы всегда быть в курсе, как пройти через HR на техническое собеседование и самопрезентовать себя, понимать, как менять карьеру и тактично спрашивать о большей ЗП.
Я рекомендую посмотреть подборку материалов, не моего авторства, по резюме, собеседованиям и оценке своей ЗП:
🔴 Ключевые лайфхаки по резюме и его ОШИБКИ
🔴 Нужны ли сопроводительные и что там писать
🔴 Как отвечать на вопрос «Расскажите о себе»
🔴 Как вести себя с неадекватом на собесе
🔴 Как рассказывать о своем факапе?
🔴 Какие книги почитать в т.ч. для успешного прохождения собеседований?
🔴 Реальные примеры офферов бизнес и системным аналитиков до 500к
Полезная подборка, если вы планируете в ближайшее время менять работу 🙂
Проходить собеседования - тоже навык, и его надо оттачивать.
Но эту тему я почти не поднимаю в канале, так как я больше "суровый технарь", который передаёт технические навыки и опыт работы 😁
А чтобы всегда быть в курсе, как пройти через HR на техническое собеседование и самопрезентовать себя, понимать, как менять карьеру и тактично спрашивать о большей ЗП.
Я рекомендую посмотреть подборку материалов, не моего авторства, по резюме, собеседованиям и оценке своей ЗП:
Полезная подборка, если вы планируете в ближайшее время менять работу 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
❤25👍9👏1
🏠 Новый проект: микросервисная архитектура для платформы аренды недвижимости #BookingGA 🏠
Теорию надо закреплять на практике. Только так реально разобраться во всей сложной
👉 В этом месяце мы проектируем архитектуру для проекта BookingGA.
Покажу вам три варианта реализации архитектуры:
+ Монолит
+ SOA
+ MSA
BookingGA — это платформа для аренды недвижимости, которая позволяет бронировать квартиры и дома как краткосрочно, так и долгосрочно, с автоматическим заключением электронных договоров и безопасной работой с персональными данными.
Основные функции платформы:
✔️ Поиск недвижимости для аренды.
✔️ Бронирование жилья — моментальное подтверждение или с подтверждением владельцем после бронирования.
✔️ Электронный договор аренды — автоматическая генерация сразу после оплаты, электронное подписание обеими сторонами и хранение документов в PDF.
✔️ Безопасные платежи — интеграция с платёжными системами, депозиты, автоматическое списание средств за аренду.
✔️ Верификация владельцев и арендаторов — проверка документов, права собственности.
✔️ Отзывы и рейтинги — оценки арендаторов и хозяев, история аренд.
✔️ Управление объявлениями — возможность владельцев редактировать, деактивировать, продвигать объявления.
✔️ Поддержка пользователей — чат с техподдержкой, система обращений.
Для пользователей будут разработаны приложения на iOS, Android и Web. Владельцы смогут управлять объектами через веб-приложение. Панель администратора поможет тех. поддержке и администраторам модерировать систему.
План работы:
0️⃣ Расскажу про нотацию C4
1️⃣ Покажу архитектуру монолита в нотации C4
2️⃣ Научу выделять сервисы и микросервисы
3️⃣ Покажу архитекту SOA и MSA в нотации C4
4️⃣ Выберем технологии для обмена данными — REST API, gRPC, GraphQL и другие
5️⃣ Посмотрим когда и зачем нужны брокеры Kafka и RabbitMQ, встроим в архитектуру
Чтобы участвовать в проекте, просто подпишитесь на канал и следите за обновлениями.
Стартуем отсюда, и следим за постами с хэштегом #BookingGA! 🙂
#АрхитектураGA
Теорию надо закреплять на практике. Только так реально разобраться во всей сложной
👉 В этом месяце мы проектируем архитектуру для проекта BookingGA.
Покажу вам три варианта реализации архитектуры:
+ Монолит
+ SOA
+ MSA
BookingGA — это платформа для аренды недвижимости, которая позволяет бронировать квартиры и дома как краткосрочно, так и долгосрочно, с автоматическим заключением электронных договоров и безопасной работой с персональными данными.
Основные функции платформы:
✔️ Поиск недвижимости для аренды.
✔️ Бронирование жилья — моментальное подтверждение или с подтверждением владельцем после бронирования.
✔️ Электронный договор аренды — автоматическая генерация сразу после оплаты, электронное подписание обеими сторонами и хранение документов в PDF.
✔️ Безопасные платежи — интеграция с платёжными системами, депозиты, автоматическое списание средств за аренду.
✔️ Верификация владельцев и арендаторов — проверка документов, права собственности.
✔️ Отзывы и рейтинги — оценки арендаторов и хозяев, история аренд.
✔️ Управление объявлениями — возможность владельцев редактировать, деактивировать, продвигать объявления.
✔️ Поддержка пользователей — чат с техподдержкой, система обращений.
Для пользователей будут разработаны приложения на iOS, Android и Web. Владельцы смогут управлять объектами через веб-приложение. Панель администратора поможет тех. поддержке и администраторам модерировать систему.
План работы:
0️⃣ Расскажу про нотацию C4
1️⃣ Покажу архитектуру монолита в нотации C4
2️⃣ Научу выделять сервисы и микросервисы
3️⃣ Покажу архитекту SOA и MSA в нотации C4
4️⃣ Выберем технологии для обмена данными — REST API, gRPC, GraphQL и другие
5️⃣ Посмотрим когда и зачем нужны брокеры Kafka и RabbitMQ, встроим в архитектуру
Чтобы участвовать в проекте, просто подпишитесь на канал и следите за обновлениями.
Стартуем отсюда, и следим за постами с хэштегом #BookingGA! 🙂
#АрхитектураGA
❤42🔥30❤🔥6👍3👏2👌2
🔥 Практическая программа по Архитектуре для СА стартует 4 марта: открыли предзапись 🔥
Погружение в архитектуру, опыт работы в сложных проектах с микросервисами и брокерами - точки роста для опытных системных аналитиков уровня Middle+.
Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.
В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks, и знакомиться с другими способами асинхронного взаимодействия систем.
Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.
Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷
Приглашаем и вас достигать новые цели вместе с нами! 🙌
🌟 Проектирование архитектуры
🗓 Старт: 4 марта 2025
👉 Подробности о программе и заявка на участие
🎁 До 25 февраля открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.
Вопросы можно задать через сайт, на почту info@getanalyst.ru или в Telegram @getanalyst.
Погружение в архитектуру, опыт работы в сложных проектах с микросервисами и брокерами - точки роста для опытных системных аналитиков уровня Middle+.
Чтобы помогать вам достигать максимального уровня в карьере, мы создали практическую программу “Архитектура систем”.
В ходе работы на ней мы будем:
✔️ Строить архитектуру проекта с нуля: монолит, сервисная, микросервисная.
✔️ Практиковаться работать с нотацией C4.
✔️ Подбирать API для проекта и учиться работать с ними на практике: REST, GraphQL, WebSocket и другие.
✔️ Ставить задачи на брокеры (Kafka, RabbitMQ), Webhooks, и знакомиться с другими способами асинхронного взаимодействия систем.
Собрали всё, что нужно для проектирования систем на самом глубоком техническом уровне для аналитиков.
Цели, которые ставят и реализуют наши аналитики в процессе обучения:
✅ Повышают грейд внутри компании
✅ Переходят из проектной разработки в продукт
✅ Структурируют знания и проходят аттестации
✅ Получают повышения
✅ Проходят собеседования и выбирают офферы по душе 🩷
Приглашаем и вас достигать новые цели вместе с нами! 🙌
🌟 Проектирование архитектуры
🗓 Старт: 4 марта 2025
👉 Подробности о программе и заявка на участие
🎁 До 25 февраля открыта предзапись на специальных условиях:
скидка + дополнительное обучение по проектированию REST API в подарок.
Вопросы можно задать через сайт, на почту info@getanalyst.ru или в Telegram @getanalyst.
🔥9👍5❤2❤🔥2
GetAnalyst_Swagger_3_Проектирование_методов_REST_API.pdf
14.6 MB
💚 Swagger - Open API - Практическое руководство. Часть 3 💚
Ранее опубликовано:
🔗 Часть 1. Регистрация аккаунта и создание демо-проекта
🔗 Часть 2. Создание собственного проекта и работа с базовыми настройками, первые строки кода
В этом посте:
👉 Часть 3. Описание методов POST и GET по спецификации OpenAPI
файл прикреплен к посту
Что внутри:
✔️ Разберетесь с блоками кода paths и components в OpenAPI
✔️ Получите готовый документ API-документации для личного портфолио с двумя описанными методами
✔️ Получите реальный опыт работы со Swagger / OpenAPI
⏳ Время на изучение и практику:
🕓 60 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу
🕓 +60 минут, если хотите выполнить ДЗ и создать личный демо-проект для портфолио
Пост не просто для сохранения, а для реального улучшения вашего технического опыта работы! 🙌
#RestApiGA
Ранее опубликовано:
В этом посте:
👉 Часть 3. Описание методов POST и GET по спецификации OpenAPI
файл прикреплен к посту
Что внутри:
✔️ Разберетесь с блоками кода paths и components в OpenAPI
✔️ Получите готовый документ API-документации для личного портфолио с двумя описанными методами
✔️ Получите реальный опыт работы со Swagger / OpenAPI
⏳ Время на изучение и практику:
🕓 60 минут — на работу с заданиями строго по руководству, где есть подсказки по каждому шагу
🕓 +60 минут, если хотите выполнить ДЗ и создать личный демо-проект для портфолио
Пост не просто для сохранения, а для реального улучшения вашего технического опыта работы! 🙌
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30❤7❤🔥4👍4
🔷 Нотация С4 для документирования архитектуры 🔷
Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично!
Но иногда автора схемы можно понять по-разному. И могут быть вопросы как её развивать дальше.
Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией моделирования архитектуры C4 👇
C4 помогает архитекторам, разработчикам и аналитикам представлять архитектуру системы в виде четырех уровней:
👉 Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам
👉 Контейнеры (C4 / Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
👉 Компоненты (C4 / Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.
👉 Код (C4 / Code)
На этом уровне детализируют каждый компонент c C4 / Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.
Материалы:
🔗 Официальный сайт C4
🔗 Пример архитектуры C4 в Miro
🔗 Нотация С4 — примеры диаграмм и инструменты
Основные инструменты:
🔗 Draw.io
🔗 Structurizr
Элементы нотации с пояснениями в картинках к посту.
#АрхитектураGA
Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично!
Но иногда автора схемы можно понять по-разному. И могут быть вопросы как её развивать дальше.
Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией моделирования архитектуры C4 👇
C4 помогает архитекторам, разработчикам и аналитикам представлять архитектуру системы в виде четырех уровней:
👉 Контекст (C4 / Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники вокруг - внешние
✔️ Пользователи
👩💻 Полезна бизнес- и техническим специалистам
👉 Контейнеры (C4 / Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.
👩💻 Полезна архитекторам, разработчикам и системным аналитикам.
👉 Компоненты (C4 / Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.
👉 Код (C4 / Code)
На этом уровне детализируют каждый компонент c C4 / Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.
Материалы:
Основные инструменты:
Элементы нотации с пояснениями в картинках к посту.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤19👍10🔥8😁1🤩1
🔵 C4 / Context - разбор на примере 🔵
Уровень Context в нотации C4 используется, чтобы дать высокоуровневое представление о системе и ее окружении.
Он помогает понять что делает система, какие пользователи с ней взаимодействует, какие другие системы с ней связаны - интеграции.
Схема легко читается как бизнес-владельцами продукта, так и разработчиками.
👉 Что нужно показывать?
🔹 Основную систему – объект проектирования (например, интернет-магазин, банковское приложение).
🔹 Пользователей – кто взаимодействует с системой (клиенты, администраторы, партнеры).
🔹 Другие системы – с чем интегрируется (платежные сервисы, справочники, ЭДО и другие системы).
🔹 Типы взаимодействий – основные потоки данных (например, клиент отправляет заказ в систему, система взаимодействует с банком).
👉 Что важно знать?
Мы не детализируем внутреннюю реализацию, а показываем глобальные границы и связи.
Это первый шаг проектирования архитектуры – помогает всем участникам проекта построить общее понимание системы.
👉 Пример для системы бронирования жилья - проект #BookingGA
✔️ Основная система:
BookingGA
✔️ Пользователи:
владельцы жилья,
арендаторы,
сотрудники тех поддержки,
администраторы платформы
✔️ Внешние системы:
платежная система РайфПэй (Интернет-эквайринг),
сервис parser-api для проверки паспортов
сервис reestrnet для проверки документов на жильё
Схема архитектуры в C4/Context по проекту прикреплена к посту 🙌
#АрхитектураGA
Уровень Context в нотации C4 используется, чтобы дать высокоуровневое представление о системе и ее окружении.
Он помогает понять что делает система, какие пользователи с ней взаимодействует, какие другие системы с ней связаны - интеграции.
Схема легко читается как бизнес-владельцами продукта, так и разработчиками.
👉 Что нужно показывать?
🔹 Основную систему – объект проектирования (например, интернет-магазин, банковское приложение).
🔹 Пользователей – кто взаимодействует с системой (клиенты, администраторы, партнеры).
🔹 Другие системы – с чем интегрируется (платежные сервисы, справочники, ЭДО и другие системы).
🔹 Типы взаимодействий – основные потоки данных (например, клиент отправляет заказ в систему, система взаимодействует с банком).
👉 Что важно знать?
На этом уровне НЕ важно, какая архитектура будет использована – монолит, микросервисы, сервисы.
Мы не детализируем внутреннюю реализацию, а показываем глобальные границы и связи.
Это первый шаг проектирования архитектуры – помогает всем участникам проекта построить общее понимание системы.
👉 Пример для системы бронирования жилья - проект #BookingGA
✔️ Основная система:
BookingGA
✔️ Пользователи:
владельцы жилья,
арендаторы,
сотрудники тех поддержки,
администраторы платформы
✔️ Внешние системы:
платежная система РайфПэй (Интернет-эквайринг),
сервис parser-api для проверки паспортов
сервис reestrnet для проверки документов на жильё
Схема архитектуры в C4/Context по проекту прикреплена к посту 🙌
#АрхитектураGA
❤14🔥5👌5👍2