GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

📚 Нотация C4: полный гайд по моделированию архитектуры с примерами, разбором ошибок и промптом для ИИ Я подготовила для вас новую большую статью по нотации C4 — максимально полную и актуальную на 2026 год. Она стала продолжением и значительным дополнением моей первой статьи о C4, которую я опубликовала ещё в 2023 году. За это время материал набрал более 280 тысяч просмотров, а я собрала огромное количество новых примеров, вопросов и типичных ошибок. В новой статье я максимально подробно разобрала: ✔️ каждый уровень и элемент нотации C4 на примерах ✔️ распространённые ошибки и спорные вопросы ✔️ инструменты для создания диаграмм ✔️ примеры кода для Structurizr ✔️ как строить C4 через AI 👉🔥 Много схем, картинок и практических примеров, готовый код Structurizr и промпт для ИИ. Это максимально практическое руководство. С ним можно сесть и самостоятельно разобраться в C4 с нуля или использовать статью как шпаргалку, когда на проекте возникает спорный вопрос. 🔗 Ссылка на статью с полным руководством по нотации C4 Сохраняйте и отправляйте коллегам — теперь у нас есть один большой материал, в котором действительно собрано всё по C4 💙 P.S. На статью потрачено почти 3 года для сбора примеров и 14 часов работы по разработке новых примеров и понятных теоретических материалов. P.S.S. ❤️‍🔥❤️🔥 и комментарии очень помогут собрать энергию, чтобы делать ещё больше полезного для вас)) P.S.S.S. Это правда крутой материал, теперь буду ссылаться на него в наших обучениях по Интеграциям и Архитектуре. 📱 Tg | 💙 ВК | 💬 Max

«Я сегодня до шести» 🤡 📱 Tg | 💙 ВК | 💬 Max

🔔 6 главных событий осени в GetAnalyst, на которые стоит обратить внимание и сохранить в календарь 🍁🔥 Ближайшие недели будут насыщенными! Открытые практикумы, новые онлайн-занятия и старты больших программ для аналитиков разного уровня 🎉 Все даты и ссылки — в одном посте 👇 ==================== ⏰⏰ Успеть до завтра [всё по Архитектуре для СА] ✨ Хореография, брокеры и API Gateway: как проектировать сквозные процессы в микросервисах Открытый практикум. 📹 4+ часа обучения в записи 🗓 Доступ — до 15 сентября, 23:59 МСК На примере одного сквозного процесса разберёте микросервисы, API Gateway, Kafka, RabbitMQ и Saga-хореографию. 🔗 Получить бесплатный доступ 👩‍🎓 Проектирование архитектуры Практическая программа для получения нового опыта работы. 🗓 Старт — 15 сентября 🖥 Первый онлайн-практикум — 22 сентября 🎁 Сегодня последний день сниженных цен Создана для системных аналитиков Middle+ и старших бизнес-аналитиков, которым важно научиться проектировать архитектуру, а не просто читать готовые схемы. За три месяца разберём архитектурные шаблоны, API, C4, брокеры, распределённые данные и влияние нефункциональных требований на систему. 🔗 Посмотреть программу и форматы участия ==================== 🟢🟢 Ближайшие онлайн-практикумы 📌 Маппинг данных: БД и JSON 🗓 21 сентября, 19:00 МСК ✅ 2.5 часа онлайн 📹 Доступ к записи после 🎁 Урок "Использование AI для проектирования БД + SQL" в подарок. Будем формировать JSON для API на основе БД и интерфейса, описывать маппинг в требованиях и автоматизировать часть работы с помощью ИИ. ▫️ Стоимость участия от 1 650 руб 🔗 Подключиться к практикуму 🧡 Асинхронная интеграция с ИИ-сервисом: от архитектуры до требований в Confluence 🗓 24 сентября, 19:00 МСК ✅ 3 часа онлайн Спроектируем всю цепочку: REST API, очередь, брокер, воркер, статусы, ретраи и ошибки. Затем оформим требования и диаграммы в Confluence с помощью ИИ, и разберём, где он мог ошибиться. ▫️ БЕСПЛАТНО 🔗 Зарегистрироваться бесплатно ==================== 🎓🎓 Важные программы осени 🚀 Системный аналитик: с нуля до опыта работы на проекте 🗓 Старт — 1 октября 🟢 Онлайн-практикумы в течение 10 месяцев Для тех, кто начинает путь в системном анализе, переходит из смежной профессии или хочет систематизировать знания. Индивидуальный план обучения, работа над проектом с нуля, создание портфолио и подготовка к собеседованиям. ❗️ Программа проводится только один раз в год. 🔗 Узнать, как проходит обучение 🧡 Интеграции систем 🗓 Старт — 7 октября 🖥 Первый онлайн-практикум — 14 октября Полный цикл работы аналитика над интеграцией на реальных задачах: от сценариев и выбора API до маппинга, безопасности, UML, асинхронного взаимодействия и постановки задач разработчикам. ❗️ Следующий поток уже в 2027 году. 🔗 Посмотреть программу курса ==================== Не знаете, что выбрать под свой опыт и рабочие задачи? Напишите @getanalyst — поможем сориентироваться. Всем классной и продуктивной недели! 🥰 📱 Tg | 💙 VK | 💬 Max

Выбор за тобой. Ничего не менять — тоже выбор. И пока ты его делаешь, кто-то другой готовится занять твоё место 👍 📱 Tg | 💙 ВК | 💬 Max

🟢🔥 4 бесплатных занятия по архитектуре — доступ до 15 сентября Сегодня утром открыли доступ к бесплатному практикуму. Он поможет перестать мыслить отдельными экранами и API-методами, и начать видеть сквозной процесс целиком — с микросервисами, синхронными и асинхронными взаимодействиями, брокерами и точками отказа: 🧩 Хореография, брокеры и API Gateway: как проектировать сквозные процессы в микросервисах Внутри — четыре занятия на примере одной архитектурной задачи: 👉 Урок 1. Микросервисы: как и зачем проектировать 👉 Урок 2. API Gateway 👉 Урок 3. Kafka и RabbitMQ 👉 Урок 4. Saga-Хореография микросервисов: практика Почему стоит пройти это обучение: ✔️ поймёте, как устроены сквозные процессы в распределённой архитектуре ✔️ разберётесь, где использовать синхронное взаимодействие, а где — брокер и события ✔️ закроете пробелы, которые мешают обсуждать решения с разработчиками и архитекторами на одном языке ✔️ лучше подготовитесь к архитектурным задачам и вопросам на собеседованиях уровня Middle+ / Senior 📹 4,5 часа практического обучения в записи 🕘 Смотреть можно в удобное время ⏰ Доступ закроется 15 сентября в 23:59 МСК 🔗 Получить бесплатный доступ 📩 Если уже зарегистрированы, проверьте почту — письмо с доступом отправили сегодня утром. Если зарегистрируетесь сейчас, письмо придёт на указанный адрес. Если его нет во входящих, проверьте папку «Спам» или напишите @getanalyst. Продуктивных выходных! 🚀 📱 Tg | 💙 ВК | 💬 Max

📚 Брокеры: полная подборка для системных аналитиков 📚 Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой: 📌 Брокеры и очереди — общая теория 📚 Очередь сообщений - что это и как работает? 📝 Всё про брокеры: как работают и зачем нужны 📝 Очередь vs Брокер: вопросы с подвохом 📝 Хореография и оркестрация в микросервисной архитектуре 📝 7 вопросов с подвохом по Архитектуре: хореография + понимание брокеров в EDA 📝 Kafka или RabbitMQ: как выбрать брокер под задачу 📌 Kafka 📙 Официальная документация 📝 Kafka - что надо знать для работы СА 📝 Устройство Kafka 📝 Алгоритм работы Kafka 📝 Как встроить Kafka в архитектуру, и главное зачем 📝 Пример использования Kafka - проект #FarmFreshGA 📝 Kafka в деле: подробный разбор примера использования в МСА 🎧 Kafka: что нужно знать Системному аналитику 📌 RabbitMQ 📙 Официальная документация 📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах 📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ 🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 🎧 Почему падает RabbitMQ: реальный кейс, который должен знать аналитик 📌 Постановки задач / ТЗ 📝 Пример реального интеграционного Use Case: с микросервисами, cron и kafka - проект BookingGA 📝 Пример технического Use Case с брокером в микросервисной архитектуре - проект GreenChargeGA 📚 Книги ▫️ Apache Kafka. Потоковая обработка и анализ данных. Гвен Шапира ▫️ Kafka в действии. Дилан Скотт ▫️ Проектирование событийно-ориентированных систем. Бэн Стопфорд (есть в открытом доступе) 🔖 Пересылайте в Избранное — поможет для структурирования знаний, практики с инструментами, и подготовки к собеседованиям 🤝 #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🎁🚀 Дарю бесплатный билет на IT-конференцию «Стачка 2026» в СПб, 3–4 октября Если вы раньше не слышали про Стачку — это большая профессиональная IT-конференция для разработчиков, аналитиков, архитекторов, тестировщиков, руководителей и других IT-специалистов. В этом году будет 150+ докладов: системный и бизнес-анализ, архитектура, разработка, ML/DS, AI-агенты и много других направлений. А одна из главных тем конференции — как ИИ меняет работу в IT. 📍 Стачка пройдёт 3–4 октября в Санкт-Петербурге. И у меня есть 1 офлайн-билет, который я хочу отдать кому-то из вас 💙 Сразу главное условие: ❗️ вы будете в Санкт-Петербурге 3–4 октября или готовы самостоятельно приехать на конференцию Если да — участвуйте 👇 Представьте, что вас позвали выступить на IT-конференции 🎤

👉 Как назывался бы ваш доклад?

Можно серьёзно, можно смешно 😄 Достаточно одного названия в комментариях. Например: «Почему webhook — это ещё не асинхронная архитектура» или «Как объяснить бизнесу, зачем нам Kafka, и не быть уволенным» 😅 ✅ Среди всех участников выберу одного победителя за самое креативное и/или полезное название доклада. А если вам будет актуально, то обязательно приглашу с этой темой в наш подкаст 😉 Если вы ещё не состоите в чате GetAnalyst и комментарии недоступны, подайте заявку на вступление. Чтобы я быстрее нашла вашу заявку, напишите @getanalyst в личку кодовое слово «Стачка». 🎟 Победителю — билет на Стачку 2026 ➕ Для нашего сообщества организаторы Стачки также дали промокод getanalyst2026 — скидка 20% на билет. 👉 Итоги объявлю 19 сентября, в комментариях + отдельным постом в канале. P.S. На конференции будет моя коллега 💙 За пару дней до Стачки расскажу, как её найти. Можно будет познакомиться, пообщаться и забрать полезные подарки от GetAnalyst Погнали 👇

Как назывался бы ваш доклад на IT-конференции?

😡 «Я системный аналитик, а не архитектор»: где реально заканчивается ваша ответственность? Эту фразу часто слышно, когда в проекте или на собеседовании нужно: ▫️ определить микросервисы ▫️ выбрать синхронное или асинхронное взаимодействие ▫️ решить, нужен ли брокер сообщений ▫️ почитать нагрузку на сервера, чем вообще DevOps-ы занимаются 😱 Если в команде есть Архитектор, финальная ответственность за архитектурное решение обычно лежит на нём. Но принять такое решение без участия аналитика сложно: именно СА глубоко понимает бизнес-процессы, данные, исключения и зависимости между системами. Поэтому задача аналитика — не единолично утверждать архитектуру, а участвовать в её проектировании, предлагать варианты и проверять, как выбранное решение будет работать в реальных сценариях Границы ролей 👇 1️⃣ Зона СА Системный аналитик отвечает за то, как система должна вести себя в конкретных сценариях: ▫️ какие компоненты участвуют в процессе ▫️ какие данные и в какой момент передаются ▫️ кто владеет данными и изменяет их ▫️ какие методы API, события и статусы нужны ▫️ что произойдёт при ошибке, повторном запросе или недоступности системы ▫️ какие проверки и бизнес-правила должны выполняться Например, недостаточно написать: После создания заказа отправить событие в брокер Нужно определить: + какое именно событие публикуется + какие данные оно содержит + кто его получает + можно ли обработать его повторно + что произойдёт, если получатель временно недоступен + когда процесс считается завершённым 👉 Это проектирование поведения системы с учетом особенностей архитектуры — прямая зона ответственности системного аналитика 2️⃣ Зона СА + Архитектора Часть решений нельзя корректно принять без понимания полной картины требований: ▫️ выделение сервисов и их границ ▫️ выбор между синхронным и асинхронным взаимодействием ▫️ использование API Gateway и брокеров сообщений ▫️ распределение ответственности за данные ▫️ выбор хореографии или оркестрации ▫️ обеспечение безопасности и отказоустойчивости Здесь СА приносит бизнес-сценарии, ограничения, данные и варианты решения, которые влияют на итоговую архитектуру. Архитектор оценивает влияние этих требований на всю систему: связанность компонентов, масштабирование, безопасность, стоимость сопровождения и соответствие архитектурным стандартам. 👉 СА не просто ждёт готовое решение Архитектора. Он участвует в его подготовке и должен уметь предложить и обосновать свой вариант 3️⃣ Зона Архитектора Архитектор отвечает за согласованность решения на уровне всей системы или нескольких систем: ▫️ целевую схему архитектуры ▫️ организацию кода ▫️ технологии ▫️ взаимодействие между компонентами ▫️ масштабирование и отказоустойчивость ▫️ безопасность ▫️ инфраструктурные требования ▫️ стоимость и сложность сопровождения ▫️ согласованность архитектурных решений между командами. При этом архитектор не обязан самостоятельно описывать каждый метод API, формат события и альтернативный сценарий. Для этого ему как раз нужен сильный системный аналитик ❗️ Где проходит реальная граница? По масштабу решения и ответственности за последствия: 🔹 Middle СA проектирует детальное поведение системы и взаимодействия в рамках задачи или подсистемы 🔹 Senior СА предлагает архитектурные варианты, оценивает ограничения и защищает решения перед командой 🔹 Архитектор отвечает за согласованность решения на уровне всей системы и целевого архитектурного ландшафта 👉 На практике эти зоны пересекаются. Особенно в продуктовых командах, где отдельного архитектора может вообще не быть. Поэтому чем выше уровень СА, тем чаще от него ждут не только требований, но и ответа на архитектурные вопросы. На практической программе «Проектирование архитектуры» мы развиваем именно эту зону: идём от требований к проектированию сервисов, данных, интеграций и сквозных процессов. 💎 Проектирование архитектуры 🗓 Старт — 15 сентября Завтра завершается предзапись на спец условиях: 🎁 сниженная цена + «Интеграции 4.0 — продвинутый уровень» в подарок 👉 Посмотреть программу и записаться ✅ Бесплатный вводный практикум

⚔️ Kafka или RabbitMQ: как выбрать брокер под задачу 📌 «Kafka — для больших высоконагруженных систем, RabbitMQ — для маленьких» — плохой критерий выбора. Брокер выбирают по модели взаимодействия: ▫️ что передаём — команду или событие ▫️ сколько получателей должны обработать сообщение ▫️ нужно ли хранить и повторно читать историю ▫️ важны ли маршрутизация, приоритеты и срок жизни сообщений Разберём по полочкам 👇 🐇 RabbitMQ RabbitMQ хорошо подходит для передачи команд и фоновых задач, которые должен выполнить конкретный обработчик: ▫️ отправить подтверждение заказа ▫️ зарезервировать товар ▫️ сформировать счёт ▫️ запустить расчёт Обычно одна задача попадает в очередь, а выполняет её один из свободных обработчиков. RabbitMQ стоит рассматривать, если: ✅ сообщение предназначено одному исполнителю ✅ нужна гибкая маршрутизация по разным очередям ✅ срочные задачи должны обрабатываться раньше обычных ✅ сообщения требуется удалять после истечения заданного срока ✅ нужны подтверждения обработки, повторные попытки и отдельная очередь (dead-letter) для сообщений, которые не удалось обработать ✅ после успешного выполнения задачи её не потребуется читать повторно. Оговорка: fanout/topic exchange в RabbitMQ умеет доставлять одно сообщение сразу нескольким независимым очередям — так что «один исполнитель» это типичный сценарий использования, а не жёсткое архитектурное ограничение. 🔥 Kafka Kafka подходит для передачи бизнес-событий — фактов, которые уже произошли: ▫️ заказ создан ▫️ оплата подтверждена ▫️ заказ отменён ▫️ доставка завершена Одно событие могут независимо обработать несколько систем. Например, событие «Заказ создан» получают: 📦 сервис склада — резервирует товар 💳 сервис оплаты — создаёт платёж 🔔 сервис уведомлений — сообщает пользователю 📊 аналитическая система — обновляет показатели Kafka стоит рассматривать, если: ✅ одно событие нужно нескольким независимым получателям ✅ события необходимо хранить и перечитывать ✅ новый получатель должен обработать ранее опубликованные события ✅ по истории событий потребуется восстановить состояние сервиса ✅ данные используются для аудита, аналитики или отслеживания изменений ✅ система обрабатывает большой непрерывный поток событий. Оговорка: хранение в Kafka не бесконечное по умолчанию — период (retention) настраивается отдельно. Если нужно хранить события вечно (что не хорошо для Kafka) — это отдельное архитектурное решение (compacted topic), а не поведение "из коробки". 👉 7 вопросов перед выбором 1️⃣ Передаём команду или событие? «Выполни действие» → чаще RabbitMQ «Действие уже произошло» → чаще Kafka 2️⃣ Сколько получателей должны обработать сообщение? Одну задачу выполняет один из доступных обработчиков → RabbitMQ. Каждый вид получателей должен независимо получить событие → Kafka (либо RabbitMQ через fanout-exchange, если история не нужна) 3️⃣ Нужно ли перечитывать историю? Если после успешной обработки сообщение больше не требуется → RabbitMQ. Если сообщения нужно хранить, повторно обрабатывать или передавать новым получателям → Kafka 4️⃣ Нужна ли сложная маршрутизация? Очереди, правила маршрутизации, приоритеты и срок жизни сообщений — сильные стороны RabbitMQ. В Kafka распределение строится через темы, разделы, ключи сообщений и группы получателей. 5️⃣ Важен ли порядок событий? Kafka сохраняет порядок только внутри одного раздела. Чтобы события одного заказа обрабатывались последовательно, в качестве ключа можно использовать идентификатор заказа. В RabbitMQ на порядок могут повлиять несколько обработчиков, повторная доставка и приоритеты. 6️⃣ Что важнее: распределение задач или история событий? Распределить задания между исполнителями → RabbitMQ. Сохранить поток событий для нескольких систем → Kafka. 7️⃣ Готова ли команда поддерживать выбранный брокер? ▫️ инфраструктура ▫️ опыт команды ▫️ требования к отказоустойчивости ▫️ стоимость сопровождения ▫️ возможности мониторинга 👉 В одной системе можно использовать оба брокера. Но только тогда, когда системе действительно нужны обе модели взаимодействия. #АрхитектураGA

📌✨ Хореография, брокеры и API Gateway: 4,5 часа практики по архитектуре для СА и БА [12-15 сентября] ✨📌 Один пользовательский запрос может запустить цепочку действий сразу в нескольких сервисах. Что оставить синхронным? Где использовать брокер? Какие события передавать? Как продолжить процесс, если один из сервисов недоступен? На новом бесплатном практикуме вы не просто изучите термины, а ➡️ пошагово разберётесь в проектировании сквозных процессов в микросервисной архитектуре. ✨ Хореография, брокеры и API Gateway: 💎 как проектировать сквозные процессы в микросервисах 👉 Внутри — четыре отдельных урока: 1️⃣ Микросервисы Как определять их границы и когда разделение системы действительно оправданно. 2️⃣ API Gateway Роль, ключевые функции, границы ответственности и практика описания процессов. 3️⃣ Kafka и RabbitMQ Очереди, брокеры сообщений и событийно-ориентированная архитектура. 4️⃣ Saga и хореография Пошаговое проектирование процесса через несколько микросервисов и асинхронные интеграции. 👉 В результате у вас сложится полноценная архитектурная картинка: ▫️ сервисы и их ответственность ▫️ синхронные API и события ▫️ API Gateway и брокеры ▫️ сквозной процесс и обработка сбоев 📹 4,5 часа практического обучения в записи 📅 Доступ только с 12 по 15 сентября 🕘 Смотреть можно в удобное время 🔗 Зарегистрироваться на бесплатный практикум Этот практикум — полноформатное вводное обучение к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 15 сентября. Если захотите продолжить обучение, глубже разобраться в архитектуре и увереннее проектировать сложные процессы — присоединяйтесь 🙌 Вопросы? Пишите @getanalyst или на info@getanalyst.ru.

🔀❌ API Gateway нужен не всегда: 6 способов организовать вход в Backend 🔀❌ API Gateway — это компонент архитектуры, который выступает единой точкой входа для клиентских запросов к backend-системе и перенаправляет их в нужные внутренние сервисы. Ключевые задачи: ▫️ маршрутизация запросов ▫️ аутентификация и авторизация ▫️ ограничения нагрузки (rate limiting) ▫️ единые логирование и мониторинг ▫️ преобразования запросов/ответов, ▫️ агрегация данных из нескольких сервисов. При этом API Gateway не владеет данными и не управляет бизнес-процессами. Это его особенность. На архитектурных схемах перед микросервисами часто "по умолчанию" появляется API Gateway. ✅ Есть микросервисы? Значит, нужен API Gateway. ❌ Но это не обязательное правило. API Gateway — только один из способов организовать взаимодействие клиентских приложений с Backend. Важно знать альтернативы: 1️⃣ Прямое обращение к монолиту Если Backend представляет собой одно приложение, клиент может обращаться непосредственно к нему. Отдельный API Gateway здесь точно не нужен: маршрутизировать запросы между несколькими Backend-сервисами просто некуда. При этом перед приложением всё равно могут находиться инфраструктурные компоненты: reverse proxy, load balancer или Ingress. 2️⃣ Сервис-ядро В сервис-ориентированной архитектуре может быть главный "сервис-ядро" — основная точка входа и владелец ключевых бизнес-процессов. Это аналог оркестратора. Клиент обращается к сервису-ядру, а тот вызывает сервис уведомлений, файловый сервис, сервис отчётности и другие вспомогательные компоненты. Важно правильно назвать такой компонент. Если он выполняет бизнес-логику и управляет процессами — это сервис-ядро, а не API Gateway. 3️⃣ Прямое обращение к нескольким сервисам Клиент может вызывать публичные API сервисов напрямую. Подход допустим, если сервисов немного, их контракты стабильны, а все точки входа действительно можно открыть клиенту. Но клиент начинает знать внутреннюю структуру Backend. При изменении границ сервисов придётся менять и клиентское приложение. 4️⃣ Backend for Frontend (BFF) Для каждого типа клиентского приложения создаётся свой Backend: ▫️ BFF для мобильного приложения ▫️ BFF для веб-интерфейса ▫️ BFF для админки BFF адаптирует данные под конкретный интерфейс и объединяет обращения к нескольким сервисам. Это особенно полезно, когда у клиентов разные сценарии, модели данных и требования к скорости ответа. При этом BFF и API Gateway могут использоваться вместе. 5️⃣ Reverse proxy, Load Balancer или Ingress Если нужно только: ▫️ принять HTTPS-запрос, ▫️ завершить TLS, ▫️ распределить нагрузку, ▫️ направить запрос в нужный сервис, то может быть достаточно инфраструктурного прокси или Ingress. Полноценный API Gateway нужен, когда появляются дополнительные задачи: управление API, проверка токенов, rate limiting, квоты, трансформация запросов и централизованные политики доступа. 6️⃣ Интеграционная шина — ESB В сервис-ориентированной или legacy-архитектуре запрос может поступать через интеграционную шину. ESB маршрутизирует сообщения, преобразует форматы и протоколы, связывает внутренние и внешние системы. Но шина — не просто другое название API Gateway или Kafka. Если перенести в неё всю бизнес-логику и подключить к БД, она станет сложным центральным компонентом, от которого будут зависеть все интеграции. 👉 Как понять, что нужен именно API Gateway? Берём его, когда необходимо: ✔️ скрыть внутреннюю структуру сервисов ✔️ предоставить клиентам единую точку входа ✔️ централизовать авторизацию и лимиты запросов ✔️ маршрутизировать вызовы между публичными API ✔️ централизировать мониторинг и логирование "из коробки" ✔️ управлять версиями API При этом количество сервисов — не главный критерий. Пять сервисов с мобильным приложением, партнёрским API и разными моделями доступа могут потребовать Gateway. А двадцать внутренних сервисов, скрытых в одном Backend, могут не требовать публичного Gateway, а требовать BFF или иного подхода. А какое решение у вас на проекте? Делитесь в комментариях 🙏 📱 Tg | 💙 ВК | 💬 Max

🧠 Задача к собеседованию на Senior СА: найдите 5+ ошибок в C4/Container схеме архитектуры 🐞 Коллега приносит вам на ревью C4/Container для нового проекта — платформы сети постаматов, через которую маркетплейсы и интернет-магазины будут доставлять отправления получателям. Можно ли согласовать эту архитектуру и передать её команде в разработку? 🔗 схема в высоком разрешении 🔗 о проекте На первый взгляд всё выглядит убедительно: ▫️ определены пользователи и внешние системы, ▫️ выделены микросервисы и базы данных, ▫️ добавлены API Gateway и Kafka, ▫️ подписаны технологии и взаимодействия. Но на этой схеме архитектуры точно есть проблемы... 🐞🐛🪲 Ошибки спрятаны на двух уровнях: 1️⃣ В использовании нотации C4 2️⃣ В проектировании архитектуры 👉 Задача: за 10 минут найти минимум 5 ошибок. По каждой напишите в комментариях: ошибка → архитектурный риск → как исправить Важно объяснить, что именно из-за неё невозможно понять или что может сломаться в реальной системе. 👉 Если видите больше пяти, то пишите все. Некоторые ошибки здесь спрятаны глубже, чем кажется на первый взгляд. . . . . . . Подсказки 👇 ☑️ Технологии ☑️ Использование цветов ☑️ Асинхронный обмен ☑️ API Gateway ☑️ Интеграция через брокер ☑️ Границы системы ☑️ Уведомления . . . . Разбор схемы и ответ — опубликую в следующих постах 🔍 👉 Читаемая схема в высоком разрешении: 🔗 ссылка #PostamatGA #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🚨 Удаляем посты с материалами, книгами и гайдами из канала. Каждый второй подкаст будет платным. Бесплатных практикумов по 4+ часа больше не будет. Примерно так мог бы выглядеть GetAnalyst в любой момент. У меня случился творческий кризис и я почувствовала, что упёрлась в потолок, мне скучно и дальше движения нет)) Поэтому 2 месяца назад я обратилась за взглядом со стороны к специалисту из США, который работает с многомиллионными аккаунтами в соц сетях. А месяц назад мы провели личную консультацию. Он изучил все наши соц сети, подкасты, вебинары, практики и в какой-то момент спросил:

«А почему ты до сих пор не монетизировала этот огромный объем своей работы?»

Для рынка это вполне привычная и рабочая модель. ➡️ старый полезный контент убирается из открытого доступа и упаковывается в платный продукт ➡️ самые ценные эпизоды подкаста — по подписке ➡️ большие практики — только платно ➡️ бесплатный вебинар — максимум 60 минут, из которых 20+ продажа продукта После анализа всего GetAnalyst вывод такой:

«Ты слишком много занимаешься благотворительностью, от этого и творческий кризис» 😅

Рационально я всё понимаю. Один пост = иногда до 6 часов работы. Гайд = несколько дней. Большая онлайн-практика = детальная проработка API, БД, схем, заданий, тестирований и куча времени на подготовку. Всё, что вы видите — не пересказ ChatGPT. 📌 За 95% материалов GetAnalyst стоит сбор реального опыта и его огромная ручная обработка, от единственного автора. Меня — Екатерины Ананьевой. Но делать GetAnalyst по описанной выше модели я не хочу. У меня изначально была другая стратегия: 📌 минимум продаж и максимум реальной пользы, которую можно получить даже не покупая у нас ничего. Мне нравится, когда говорят:

«Просто открой GetAnalyst — там всё есть»

Когда наши посты сохраняют для работы. Когда по гайдам впервые открывают Postman. Когда подкаст помогает разобраться в новой теме. Когда бесплатная практика потом реально используется в работе. Да, возможно, с точки зрения монетизации это не самый эффективный путь 🤷‍♀️ Но пока именно эта стратегия для меня и есть GetAnalyst. Так что если вы давно со мной знакомы — думаю, вы понимаете, почему мне так сложно было бы сделать иначе ❤️‍🔥 А варианты решения творческого кризиса нашли. Собираю энергию и силы. Буду экспериментировать 🙌

💥 [12-15 сентября] Хореография, брокеры и API Gateway: практикум по архитектуре 💥 Разделить систему на микросервисы? Ок. Построить на них рабочий и устойчивый бизнес-процесс — гораздо сложнее. Именно здесь начинается сеньорский уровень работы системного аналитика. Senior СА — это не тот, кто просто знает определения Kafka, API Gateway и хореографии. Он понимает, как связать микросервисы в единый процесс, выбрать подходящий способ взаимодействия и описать решение так, чтобы его могла реализовать команда 🙌 Чтобы вы могли разобраться в этом на практике, мы готовим новый архитектурный практикум: 🧩 Хореография, брокеры и API Gateway: как проектировать сквозные процессы в микросервисах 📅 Доступ с 12 по 15 сентября 📹 Запись 🕘 Смотрите в удобное время 👉 За 4+ часа полноформатного обучения: ✅ Поймёте роль API Gateway в микросервисной архитектуре. ✅ Разберётесь в принципах хореографии процессов на практике. ✅ Научитесь описывать процессы в микросервисной архитектуре. ✅ Поймёте, как использовать брокеры сообщений для интеграций микросервисов. ✅ Сможете уверенно обсуждать архитектурные решения с архитекторами и разработчиками. 🔗 Зарегистрироваться Хотите начать мыслить не отдельными API-методами, а сквозными процессами всей системы, с пониманием асинхрона и брокеров? Регистрируйтесь сейчас и планируйте время на обучение заранее! 📱 Tg | 💙 ВК | 💬 Max

👩‍💻 Вайбкодинг для СА: создание приложения с помощью ИИ 🤖🧠 щё недавно системный аналитик описывал требования и передавал их разработчикам. Теперь с помощью вайбкодинга он может сам превратить идею и требования в работающее приложение. Означает ли это, что граница между аналитиком и программистом постепенно исчезает? И станет ли умение создавать решения с помощью ИИ новым обязательным навыком аналитика? В этом выпуске проверяем возможности вайбкодинга на реальном кейсе. 🔗 Сайт эпизода 🔗 Приложение: инструмент для БД и SQL Видео с демо (рекомендуется): ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify GetAnalyst — база знаний с нереальным количеством практики в открытом доступе 😍 📱 Tg | 💙 ВК | 💬 Max

💎 Архитектура для СА: открыта предзапись, старт 15 сентября 💎 Вы уже уверенный Middle, Middle+ или Senior. Понимаете процессы, работаете с интеграциями и API. Микросервисы в теории понятны. Знаете, зачем нужна Kafka. Но как спроектировать реальный асинхронный процесс, в котором участвуют несколько сервисов? 🔴 Почему, например, остановка одного сервиса всё ещё блокирует процесс, несмотря на Kafka? Потому что асинхронный обмен не отменяет зависимость между шагами. Если следующий шаг требует результата предыдущего, сообщение в брокере этот результат не заменит. Нужно определить, где процесс может продолжаться независимо, где должен ждать и что произойдёт, если ожидание затянется. От определения микросервисов и выбора технологий — к проектированию процессов между ними. На этом строится наш практический курс «Проектирование архитектуры» для системных аналитиков уровня уверенный Middle / Middle+ / Senior. 👉 Посмотреть программу Что будем делать ▫️ Проектировать архитектуру с нуля: выбирать между монолитом, сервисной и микросервисной архитектурой. ▫️ Описывать архитектуру упрощенными схемами и с помощью нотации C4, чтобы обсуждать решения с командой. ▫️ Выбирать способы взаимодействия: REST, GraphQL, WebSocket и другие. ▫️ Проектировать асинхронные взаимодействия с Kafka и RabbitMQ, работать с вебхуками и описывать требования для разработчиков. После практики с нами ✔️ Приходите на архитектурный митинг и ведёте его, а не просто участвуете. ✔️ Обосновываете повышение грейда конкретными навыками. ✔️ Проходите технические собеседования и сами выбираете оффер. ✔️ Переходите из проектной разработки в продукт с SOA или микросервисами. ✔️ Закрываете пробелы, которые давно хотели закрыть, и собираете своё публичное портфолио. Процесс 12 онлайн-практикумов и теоретические модули в записи: разбираем демонстрационный проект и применяем подходы на дополнительном проекте для закрепления навыков. ✅ Домашние задания и обратная связь — на всех тарифах. Глубина проверки зависит от тарифа. 💎 Проектирование архитектуры 🗓 Старт 15 сентября Предзапись до 11 сентября 🎁 скидка + мини-курс «Интеграции 4.0 — продвинутый уровень» в подарок 👉 Посмотреть программу и записаться

🧩 7 архитектурных решений, которые аналитик принимает раньше архитектора «Пользователь заказал товар, курьер загрузил посылку в постамат, пользователь её забрал». Один процесс. Но сколько вопросов появляется, когда начинаешь его проектировать: ▫️ какие микросервисы нужны ▫️ где хранить данные об отправлениях, ячейках и оплатах ▫️ какие API использовать ▫️ где ждать ответ, а где передавать событие через брокер ▫️ кто вообще имеет право открыть ячейку И это вопросы, с которыми системный аналитик сталкивается уже при проработке требований — ещё до готовой схемы архитектуры. Конечно, архитектурные решения принимаются вместе с архитектором и разработчиками. 👉 Но аналитику важно понимать, что именно мы выбираем и как этот выбор влияет на работу системы. В карточках разбираем 7 таких решений на примере проекта #PostamatGA. Без попытки поставить Kafka между всеми прямоугольниками 😃 📌 Сохраните последнюю карточку — пригодится при обсуждении следующей большой фичи или нового проекта. #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🔵🔥 Нотация C4 для архитектуры: теория, 7 примеров и практический видеоурок 🔥🔵 Как показать архитектуру системы так, чтобы её поняли и бизнес, и разработчики? Нотация моделирования архитектуры C4 поможет. Собрала в одном посте все материалы по C4: от теории до готовых схем с конкретными примерами 👇👇👇 🎬 Практический видеоурок: C4 за 90 минут Разбираем уровни Context, Container и Component и наглядно показываем, как проектировать архитектуру на примере двух реальных проектов. К уроку — полный комплект схем C4 / Context и C4 / Container по каждому проекту: можно посмотреть процесс, а затем изучить результат. ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram 🔗 Статья с доп. материалами 📚 Коротко по теории C4 — модель описания архитектуры системы на четырёх уровнях. Каждый следующий раскрывает детали предыдущего. 🔗 Официальный сайт C4 🔗 Нотация С4 — примеры диаграмм и инструменты 1️⃣ C4 / Context — контекст Система, её интеграции и пользователи. ✔️ Главный прямоугольник - наша система ✔️ Серые прямоугольники вокруг - внешние ✔️ Пользователи 👩‍💻 Полезна бизнес- и техническим специалистам 2️⃣ C4 / Container — контейнеры Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context. ✔️ Пользователи и внешние системы с уровня C4 / Context ✔️ Мобильные, веб- и десктоп приложения ✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway ✔️ Базы данных и файловые хранилища ✔️ Виды API ✔️ Технологии (языки программирования, СУБД, протоколы для API и др) ✔️ Базы данных и файловые хранилища ✔️ Очереди и брокеры 👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам. 3️⃣ C4 / Component — компоненты Модули кода и зависимости между ними. Детализирует один из контейнеров с C4 / Container. На каждый контейнер своя схема. Отлично подходит для детализации модульного монолита. 4️⃣ C4 / Code — код На этом уровне детализируют каждый компонент c C4 / Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация. 🛠 Основные инструменты: 🔗 Draw.io - графический 🔗 Structurizr - код 🔗 MermaidChart - код 🔗 PlantUML - код, самый неудобный Ключевые элементы нотации для каждого уровня прикреплены в картинках к посту. Необязательно рисовать все четыре уровня: выбирайте нужную детализацию под задачу и аудиторию. 🖼 Примеры схем архитектуры Можно изучать и использовать как ориентир для своих проектов. В подборке есть и монолиты, и микросервисные системы с брокерами. 🔗 RideFlow — заказ такси 🔗 TelMed — телемедицина 🔗 BookingGA — сервис аренды недвижимости 🔗 GreenChargeGA — зарядки для электроавто 🔗 CityGA — поиск мероприятий в городе 🔗 AdFlowGA — рекламный сервис 🔗 Пример архитектуры C4 в Mir 🔖Это максимально полный гайд по C4. Сохраняйте, чтобы теория, примеры и практика по C4 были под рукой, когда понадобится спроектировать архитектуру. #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max