📚 7 видов архитектуры, которые важно знать СА 📚

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

Но в сложных продуктовых компаниях, как банки, маркетплейсы, страховые и т.п., где преобладают сервисная (SOA) и микросервисная (MSA) архитектуры, аналитикам важно разбираться в этом вопросе.

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


👉 7 шаблонов проектирования архитектуры, которые важно знать и понимать СА:

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)

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


📚 В мини-книге к посту вы найдёте:
+ описание каждого подхода,
+ связи между ними,
+ картинки,
+ примеры.

Сохраняйте и пользуйтесь!


P.S. А если интересно погрузиться в архитектуру для кода, то рекомендую послушать подкаст про Чистую архитектуру


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

🅿️ Проект #ParkingGA: архитектура для системы управления парковками 🅿️

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

👉 ParkingGA — это платформа для управления парковками, которая автоматизирует процессы от поиска свободного места до оплаты и аналитики загрузки.

Основные сценарии:
✔️ Поиск парковки на карте (уличные, закрытые)
✔️ Бронирование мест
✔️ Контроль занятости мест по датчикам
✔️ Въезд/выезд по номеру автомобиля
✔️ Оплата и продление парковки
✔️ Интеграция с камерами, IoT-датчиками и платёжными системами
✔️ Отчётность для операторов парковок и города


Что будем делать:

1️⃣ Разберём подходы к проектированию архитектуры

2️⃣ Спроектируем микросервисы (МС)

3️⃣ Построим C4-модели: от уровня Context (L1) до Container (L2)

4️⃣ Изучим принципы интеграции МС: синхронные (API) и асинхронные (Kafka, RabbitMQ)

5️⃣ Погрузимся в API Gateway, хореографию и оркестрацию.

6️⃣ Разберём принципы выбора СУБД и хранения данных: PostgreSQL, Redis, NoSQL - что, зачем и почему?



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

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


Подписывайтесь на @getanalysts и следите за хэштегом #ParkingGA, чтобы изучать архитектуру и быть в курсе актуальных публикаций по проекту 🅿️

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

🟠 Domain-Driven Design (DDD): что это и зачем, разбор с примерами 🟠

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

В таких ситуациях на помощь приходит Domain-Driven Design (DDD).

📌 DDD — подход, при котором мы проектируем систему, отталкиваясь от предметной области и понимания языка бизнеса, а не от технических деталей и функциональных требований.


Ключевое:

✅ Единый язык (Ubiquitous Language)
Договариваемся, что бизнес и разработчики используют одинаковые слова, и понимают их одинаково.

Например, в системе парковок:
“Сессия” = время от въезда до выезда
“Льготный клиент” = владелец абонемента или спец. допуска

Результат — меньше путаницы в ТЗ, коде и общении.


✅ Ограниченные контексты (Bounded Context)
Делим большую систему на зоны, внутри которых термины и правила работают одинаково, а за их пределами — могут отличаться.

В системе для парковок мы понимаем, что у нас могут быть большие части:

+ Контроль доступа (камеры, шлагбаумы, проверка разрешений)
+ Платежи (расчёт тарифа, оплата, возвраты)
+ Учёт мест (свободно/занято, бронирования)

Внутри каждой части свои правила и детали, которые не мешают остальным.


💡 Важный момент:
Один Bounded Context ≠ всегда один микросервис.

Это логическая граница. Внутри неё может быть один сервис, несколько микросервисов или модуль монолита.

Но при переходе к MSA часто делают так, что каждый контекст превращается в один или несколько микросервисов.



✅ Модель предметной области (Domain Model)

Это карта всех объектов системы и их правил — в коде, БД, API.

Для системы парковки это может быть:

+ Сущности:
++ ParkingSession: начало, конец, тариф, сумма, статус оплаты.
++ Vehicle: номер, тип, льготы.
++ Spot: зона, номер, статус.

+ Правила:
++ без оплаты выезд запрещён, кроме льготных клиентов;
++ место освобождается только после закрытия сессии парковки.



👉 DDD помогает навести порядок в сложном проекте:

+ общий словарь → меньше недопонимания

+ границы контекстов → управляемая архитектура (и потенциальная основа для микросервисов)

+ модель предметной области → понятный “скелет” системы

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


Если начать проект с этих трёх шагов, то даже самая запутанная система будет спроектирована логично и её развитие будет (без) с меньшим количеством сюрпризов.


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

🔥 5 типовых сервисов и микросервисов, которые можно выделить в любой архитектуре 🔥

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

✅ Аутентификация и авторизация
Управление процессами аутентификации пользователей и контроля доступа к ресурсам системы.

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

✅ Уведомления и рассылки
Отправка уведомлений и сообщений пользователям через различные каналы (email, SMS, push-уведомления).

✅ Управление контентом (блоги на сайтах, новости и подобное)
Управление статическим и динамическим контентом (тексты, изображения, видео), организация его структуры и хранения.

✅ Биллинг и платежи
Обработка и учет платежей, интеграция с платежными шлюзами, выставление счетов. Взаимодействует с внешними платежными шлюзами и банковскими системами.


Если я работаю над проектом с нуля, то использую этот список как чек-лист “С чего начать". Поможет всем IT-специалистам в задачах, связанных с проектированием архитектуры.


В мини-книге прикрепленной к посту рассказала подробнее про каждый сервис, и почему их выделяют как независимые части систем 🙌

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

Быть честными - важно! Главное не переусердствовать! И без инцидентов с БД, пожалуйста 😄😉 #GAhahaha

🔮 Микросервисная архитектура (МСА) — современный подход к разработке высоконагруженных приложений.


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

✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).


✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.


✅ API Gateway — единая точка входа для всех клиентов API. Он маршрутизирует запросы на нужные микросервисы, благодаря чему клиентам не надо думать о том, к какому сервису обратиться для вызова конкретной функции.

Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.


✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.

Они взаимодействуют между собой с помощью легковесных протоколов, таких как HTTP (REST), gRPC или через асинхронные сообщения.


✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.

Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.


✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.


✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).


✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.


✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.


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

🅿️ DDD в деле: микросервисы для #ParkingGA 🅿️

В этом посте разберём, какие сервисы и микросервисы можно выделить для платформы управления парковками.


🔹 Аутентификация и авторизация
Отвечает за вход в систему и проверку прав.


🔹 Пользователи и автомобили
Управление профилем водителя и его машинами.


🔹 Каталог парковок
Справочник с адресами, схемами мест.


🔹 Парковочные сессии
Фиксирует факт въезда/выезда и длительность стоянки.
По сути это "заказ" парковки, если сравнивать с Интернет-магазином.


🔹 Биллинг и Тарифы
Хранит правила расчёта стоимости. Считает стоимость парковочной сессии.


🔹 Платежи
Интеграция с платёжной системой, обработка транзакций.


🔹 Виртуальные кошельки
Внутренняя учётная система для быстрых оплат.


🔹 Абонементы
Долгосрочные парковочные билеты.


🔹 Штрафы и нарушения
Фиксирует неоплаты, превышения времени, нарушения правил парковки.


🔹 Уведомления
Отправка сообщений пользователям: push, SMS, email.
Хранение и настройка шаблонов.


🔹 Лояльность
Система для проведения акций и выдачи скидок клиентам:
+ скидки,
+ акции,
+ бизнесы-партнеры,
+ промокоды.


🔹 Обращения тех. поддержки
Регистрация и обработка заявок от пользователей, переписка в рамках поддержки.


🔹 Администрирование
Управление сотрудниками, их правами и настройками.


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


🔹 Аудит
Хранит действия пользователей и администраторов.


🔹 API Gateway
Входная точка для всех запросов, маршрутизация и безопасность.
Не хранит бизнес-данных.



Сервисы выделены по доменным границам и принципу «один сервис — один владелец данных».

Такой подход позволяет:
✔️ держать чёткие зоны ответственности,
✔️ разделять нагрузки и соблюдать SLA,
✔️ обеспечивать безопасность,
✔️ развивать и масштабировать каждый сервис независимо.

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


Ещё идеи по сервисам?
Пишите в комментариях 👍

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

⚙️ 8 Шаблонов Проектирования Микросервисов ⚙️

1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.

2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.

3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.

4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.

5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.

6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.

7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.

8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.


⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.


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


Исходник: png | svg (анимация)

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

Вебинар OpenBPM Engine — российская альтернатива Camunda 7

С окончанием официальной поддержки Camunda 7 многие компании сталкиваются с необходимостью поиска надёжной замены. OpenBPM Engine предлагает решение, позволяющее сохранить текущие наработки и продолжить работу без изменений архитектуры и бизнес-логики. В сочетании с защищенными версиями операционной системой AstaLinux вы получаете безопасное полностью отечественное решение.

Приглашаем вас на вебинар, посвящённый OpenBPM Engine — российской системе управления бизнес-процессами, полностью совместимой с Camunda 7.
По окончанию вебинара вы сможете установить open source версию движка OpenBPM, чтобы оценить продукт самостоятельно.

Этот вебинар будет полезен разработчикам, архитекторам, DevOps-инженерам и IT-менеджерам, которые ищут надёжное решение для поддержки и развития бизнес-процессов после завершения жизненного цикла Camunda 7.

27 августа, 16:00 мск

Зарегистрироваться

📚4 шага, чтобы выбрать СУБД для проекта 📚

Выбор СУБД — не галочка в чеклисте, а инженерное решение для проекта.

Да, для большинства случаев (~80%) разумно стартовать с PostgreSQL для всего, кроме кэша и файлов 😃
Но так бывает не всегда...

Что может заставить задуматься о подборе СУБД для проекта:
✔️ смешанные нагрузки,
✔️ жёсткие RPO/RTO,
✔️ вид хранимых данных,
✔️ необходимость полнотекстового поиска,
✔️ сложные запросы.


📚 В мини-книге для архитекторов и аналитиков, прикрепленной к посту, вы найдёте:
+ расшифровки сложных терминов, связанных с базами данных,
+ и пошаговый алгоритм, который поможет выбрать СУБД для вашего проекта, когда «дефолтный» вариант не подошёл.

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

🌐 API Gateway | Load Balancer | Reverse Proxy | Forward Proxy | Service Mesh 🌐

Когда системы обрабатывают миллиарды запросов в день, они не "падают" благодаря правильным сетевым компонентам.

Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:


🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.


🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.


🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.


🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.


🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.



📌 Знание этих инструментов помогает аналитику не путаться в сетевых терминах и понимать масштабируемые и безопасные системы.

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