📚 Нотация С4 для описания архитектуры системы 📚

Можешь показать схему архитектуры системы без нотации, в виде прямоугольников и стрелочек? Отлично! Первый шаг к пониманию работы системы сделан. Но если мы работаем со сложной архитектурой, то в некоторых моментах будут вопросы, и автора картины можно понять по-разному.

Если в отрасли есть стандарты, лучше использовать их.
Поэтому предлагаю познакомиться с нотацией C4, где есть несколько уровней описания системы, которые помогают понять её 🙂

📚C4 - нотация моделирования архитектуры, которая упрощает визуализацию сложных систем.


Она помогает архитекторам, разработчикам и системным аналитикам представлять архитектуру в виде четырех абстракций:

👉 Контекст (C4 / Context) - система, её интеграции и пользователи.

👉 Контейнеры (C4 / Container) - независимые по коду приложения внутри системы, детализация главного прямоугольника c C4 / Context.

👉 Компоненты (C4 / Component) - модули кода и зависимости между ними, детализирует один из контейнеров с C4 / Container.

👉 Код (C4 / Code) - описывает реализацию кода для конкретных компонентов системы, детализирует C4 / Component.


Материалы для самостоятельного изучения C4:
🔗 Официальный сайт C4 (англ)
🔗 Шаблон с примером архитектуры в Miro
🔗 Нотация моделирования архитектуры С4 — примеры диаграмм и инструменты

Сохраняйте материалы в избранное, чтобы не терять 💾

#АрхитектураGA

⭐️ Гайд по C4 с примерами [Моделирование архитектуры для системных аналитиков] ⭐️

Нотация C4 - одна из самых удобных для визуализации архитектуры информационных систем. Разработана в 2011 году Саймоном Брауном, системным архитектором.

C4 - это 4 уровня детализации:
⭐️ Context
⭐️ Container
⭐️ Component
⭐️ Code

Преимущества по сравнению с нотацией Archimate: более техническая, меньше бизнес-контекста.

Все подробности собрала в прикрепленном к посту гайду.

В нём больше наглядных примеров, инструменты для C4 и полезные ссылки! Сохраняйте и пользуйтесь ❤️

#АрхитектураGA

💫 Архитектура в C4 / Context - проект RideFlow 💫

Самый верхний уровень C4 / Context показывает систему и её окружение.
Проектируя его, мы не заморачиваемся с тем, какой подход к архитектуре будет выбран — будь то монолит, сервис-ориентированная архитектура или микросервисы.

Все, что показывает C4 / Context:
1. Пользователей, которые работают с системой.
2. Интеграции с внешними системами.

Основное преимущество этого уровня заключается в его наглядности и доступности как для IT-команды, так и для бизнес-стейкхолдеров. Его может разработать как системный, так и бизнес-аналитик.

Понимание пользователей критично для определения ролевой модели системы, управления доступами и выявления потенциальных ограничений. Этот уровень также позволяет предположить, какие приложения могут быть важны для пользователей.

А интеграции это то, что нужно знать о любой системе. Это вся техническая суть C4 / Context.

Интеграции влияют на:
+ Работу отдельных бизнес-процессов в системе и синхронизацию данных по ним, а также на работу с данными в системе в целом.
+ Безопасность, так как каждая точка интеграции в системе это потенциальное место для атаки.
+ Масштабируемость, так как в системе одновременно может работать большое количество пользователей и важно понимать, как много одновременных запросов от нашей системы сможет обрабатывать внешняя система.

Пример схемы проекта по заказу такси #RideFlow поможет нам понять, как реализуется C4 / Context на практике. См. картинку к посту.

Вопросы по схеме? Пишите комментарии.
Всё понятно и готовы идти дальше? Ставьте 👍

#АрхитектураGA

🌱 Архитектура для аналитиков: опыт работы и рост здесь 🙌

Погружение в архитектуру систем и опыт работы в сложных проектах с микросервисной архитектурой - точки роста для опытных системных аналитиков.

Поэтому, по вашей обратной связи, в этом году я запустила новую практическую программу для системных аналитиков, которая позволяет расширить экспертизу в архитектуре систем.

🌟 Проектирование архитектуры
🌟 Старт предобучения 29 августа 2024
🌟 Подробности о программе и запись

🎁 С 14 до 22 августа открыта предзапись на специальных условиях + дополнительное обучение по REST API в подарок.

В архитектуре я проявила максимальные занудство и дотошность. Собирала не только свой опыт, но и подключила других экспертов.

Один из важных отзывов, повторяемый разными словами в чатах:

“Есть возможность попрактиковаться в проектировании архитектурного решения, выйти за пределы "пузыря" моей работы и налаженных процессов на работе”

Программа подойдёт только для опытных системных аналитиков (Middle и выше), кто уже работал с интеграциями, хочет расти в Senior внутри компании, или переходить в интересные и сложные проекты.

Навыки работы с архитектурой, очередями, API, взаимодействием систем в реальном времени, которые аналитики получили в ходе работы, уже сейчас помогают им:
+ проходить аттестацию в компании на повышение грейда,
+ менять работу и выбирать офферы по душе,
+ получать повышения.

Создавать IT-таланты в Системном Анализе - цель GetAnalyst.
И Архитектура - самая сложная, но самая интересная часть в этом пути 🙌

2024 - год больших и крутых перемен ♥️ Давайте идти к ним вместе!

🔸 Монолит, Сервисная и Микросервисная архитектура - сравнение 🔸

Для системных аналитиков важно не только знать, какие виды архитектур существуют, но и понимать их ключевые отличия и области применения. В этом посте мы познакомимся с наиболее распространенными видами архитектуры.

🔸 Монолитная архитектура
В монолитной архитектуре все компоненты приложения находятся в одной кодовой базе и работают как единое целое. Это обеспечивает простоту разработки и релизов системы.
Хорошо подходит для стартапов и небольших проектов.

БД:
Обычно используется одна БД, что упрощает взаимодействие между различными частями приложения, но может стать узким местом при масштабировании.

Внутренние интеграции:
Все компоненты взаимодействуют только на уровне кода. Интеграции между ними по API и другими способами не нужны. Внутренние интеграции могут быть только при наличии очередей или брокеров сообщений.


🔸 Сервисная архитектура SOA (Service-Oriented Architecture)
SOA разделяет функциональность на отдельные сервисы, которые взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.

Идеально подходит для средних и крупных проектов, где важно обеспечивать высокий уровень доступности или производительности для отдельных частей системы.

Например, в Интернет-магазине сервис каталога и сервис заказов можно поделить, чтобы инсталлировать на сервере 10 копий сервиса каталога, но всего 3 копии сервиса заказов, т.к. до заказа товаров доходит меньше пользователей чем тех, кто просто смотрит каталог.

БД:
Каждый сервис может использовать свою собственную БД, что облегчает масштабирование и изоляцию сервисов, но также несколько сервисов могут использовать одну БД, что отличает SOA от MSA.

Внутренние интеграции:
Сервисы интегрируются через API, что упрощает интеграцию. Могут использовать шину - ESB.

#АрхитектураGA

Продолжение 👇

🔸 Микросервисная архитектура MSA (Microservice Architecture)
MSA состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет одну бизнес-функцию.

Микросервисы меньше по функциональности чем сервисы. Это обеспечивает высокий уровень масштабируемости и гибкости, но из-за большого количества сервисов такие проекты дорого сопровождать, в частности из-за необходимости опытной и высоко-квалифицированной команды.

Подход эффективен для больших и быстро-развивающихся приложений, где требуется быстрая разработка и частые обновления.

БД:
Каждый микросервис, в идеале, управляет своей собственной БД, что позволяет избежать зависимостей и упрощает масштабирование каждого сервиса по отдельности.

Внутренние интеграции:
Взаимодействие между микросервисами часто строится по API на легких протоколах, таких как REST или gRPC, и может включать очереди и брокеры сообщений для асинхронной коммуникации.



👉 Выбор архитектуры проекта зависит от специфики и требований к системе.

На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

🧐 Основная рекомендация опытных архитекторов:

Начинай стартап с монолита и сразу правильно организуй модули кода в нём, которые потом можно будет выделить в отдельные сервисы и микросервисы.

Ключевые подходы к проектированию архитектуры фиксируются в проектной документации. И это не только схемы архитектуры, но и правила, по которым продолжать развивать проект всей команде.

Понимание ключевых аспектов каждого подхода поможет аналитикам определить наиболее подходящую архитектуру для конкретного случая, а также принимать активное и осознанное участие в обсуждениях с разработчиками и архитекторами 🌱

#АрхитектураGA

👩‍💻🧑‍💻 Как проводят собеседования на системного аналитика: про найм и подготовку к смене работы 🧑‍💻👩‍💻


Смена работы часто сопровождается стрессом и "синдромом самозванца". Мы хотим помочь побороть их. В эпизоде разберем структуру собеседований, вакансии и актуальные навыки аналитиков, чтобы добавить уверенности в новом шаге для вашей карьеры.

01:17 - Актуальные вакансии в компаниях и почему они появляются.

04:37 - Кто составляет вакансии системных аналитиков и задает требования к кандидатам.

10:46 - Структура собеседования на системного аналитика. Теоретические и практические вопросы. Какого уровня системных аналитиков ищут, какой опыт нужен и что ожидают от кандидатов.

17:24 - Про зубрежку теории: почему это не работает на пользу кандидату. Подробный список вопросов собеседования и требований к системным аналитикам от СберЗдоровье.

21:54 - Отношение к собеседованию на 1.5 часа и техническим задачам во время собеседований.

30:04 - Про найм джунов (младших системных аналитиков): ожидания по навыкам и опыту. Цитата из эпизода: “Джуны - единственная сила, которая работает”.

35:21 - Процесс онбординга: что происходит после успешного найма системного аналитика. Как можно помочь адаптироваться новому сотруднику в IT-компании.

42:57 - Ожидания от нанятых сотрудников в течение испытательного срока. 

46:40 - Сложности высадки новых сотрудников. Истории провального найма системных аналитиков. И про обязательный выходной по средам.

52:27 - Удаленка и построение взаимоотношений в компании. Интересные решения по развитию корпоративной культуры ИТ-компаний.

59:53 - Рекомендации по подбору сотрудников для руководителей в ИТ и по смене работы и собеседованиям для системных аналитиков.

Ведущая:
Екатерина Ананьева

Гости:
Никита Финько, Росбанк
Ольга Пашкова, СберЗдоровье


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify


Ждём вопросы в комментариях, чтобы рассказать больше в следующем эпизоде 😉

Просто помни об этом 😉

💫 Пример C4 / Container для монолита с брокерами, БД и ФХ - проект RideFlow 💫

Рассказала теорию про основные виды архитектуры: монолиты, сервисы и микросервисы.
Показала пример схемы монолита #RideFlow без нотаций.
А теперь хочу показать этот же монолит, но уже с использованием нотации C4 / Container.


➡️ C4/Container расширяет расширяет предыдущий уровень C4/Context, на котором вид архитектуры уже точно должен быть понятен.

➡️ Основное на схеме C4 / Container для монолита (🔗ИСХОДНИК):
- Пользователи
- Внешние системы, оборудование
- Приложения с UI
- Монолитное сервер-приложение - Backend
- Базы данных - для монолита обычно одна, отдельные схемы не отражают
- Файловые хранилища
- Очереди, брокеры


Почему я подробно показываю и разбираю монолиты?

С монолитами работают многие из нас. И когда мы ясно понимаем, что такое монолит и как он выглядит на схеме архитектуры, то понять микросервисы будет уже легче.

Монолит идеален для небольших проектов и стартапов. И можно остановиться на нём для RideFlow, но...

Монолит - идеальное решение, если мы делаем разработку с нуля, пока у нас нет пользователей и масштабных нагрузок.
К микросервисам для RideFlow мы перейдем далее,

чтобы посмотреть на отличия схем для одного и того же проекта в разной архитектуре.

Дополнительно про "жесткий монолит":

В нашем проекте мы избегаем "жесткой монолитной архитектуры" — мы не будем смешивать код пользовательского интерфейса веб-приложений (UI) и Backend (серверной логики и обращений к БД), как это обычно бывает в монолитах.
Такое решение обусловлено наличием мобильных приложений, для которых потребуется разработка API.

➡️ Итого:
На схеме показана современная версия монолитной архитектуры, где монолитом является только Backend (приложение сервера).


Внутри монолитного Backend можно будет организовать функциональные модули.
Их, согласно нотации C4, показывают на следующем уровне - C4/Component.
Модульный монолит в будущем поможет легче переехать на сервисную или микросервисную архитектуру.

#АрхитектураGA