📌 84 термина по Архитектуре, которые важно знать Системному Аналитику 📌

◻️ Общие архитектурные понятия
1. Архитектура системы
2. Компонент
3. Модуль
4. Подсистема
5. Сервис
6. Backend
7. Frontend
8. Web-приложение
9. Сайт
10. Desktop-приложение
11. Мобильное приложение
12. Виджет

🧱 Архитектурные стили и подходы
13. Монолитная архитектура
14. Модульный монолит
15. Сервис-ориентированная архитектура (SOA)
16. Микросервисы (MSA)
17. Событийно-ориентированная архитектура (EDA)
18. Слоистая архитектура
19. API Gateway
20. Хореография
21. Оркестрация
22. Service Registry and Discovery
23. Backend for Frontend (BFF)
24. Database-per-Service (БД на сервис)
25. CQRS (Command Query Responsibility Segregation)
26. Domain-Driven Design (DDD)
27. Event Storming
28. Чистая архитектура

🔗 Интеграция и взаимодействие компонентов
29. API (Application Programming Interface)
30. REST API
31. GraphQL
32. gRPC
33. SOAP
34. WebSocket
35. Синхронное взаимодействие
36. Асинхронное взаимодействие
37. Webhooks
38. Polling
39. Long Polling
40. Message Broker (Брокер сообщений)
41. Kafka
42. RabbitMQ
43. ESB (Enterprise Service Bus)

💾 Хранение данных
44. База данных (БД)
45. СУБД
46. Реляционные БД (PostgreSQL, SQLite, MySQL, Oracle и др.)
47. NoSQL БД (MongoDB, Redis и др.)
48. Файловое хранилище
49. Шардирование
50. Репликация
51. Кэширование

🔐 Безопасность
52. Authentication (Аутентификация)
53. Authorization (Авторизация)
54. SSO (Single Sign-On)
55. OAuth 2.0
56. JWT
57. Token
58. Bearer Token
59. Basic Authentication
60. Keycloak
61. TLS
62. HTTPS
63. WWS
64. Аудит

🖼 Нефункциональные требования (НФТ)
65. Масштабируемость
66. Доступность
67. Отказоустойчивость
68. Производительность
69. Сопровождаемость
70. Безопасность

⚙️ DevOps и инфраструктура
71. CI/CD (Continuous Integration / Continuous Delivery)
72. Балансировщик нагрузки (Load Balancer)
73. Docker
74. Kubernetes
75. Service Mesh
76. Мониторинг (Prometheus, Grafana, Zabbix и др.)
77. Логирование (ELK с Kibana, Loki + Grafana и др.)
78. Дашборды
79. Tracing
80. Health Check

📐 Проектирование и документация
81. UML Sequence Diagram
82. UML Activity Diagram
83. C4 Model (Context, Container, Component, Code)
84. Archimate
85. ERD (Entity-Relationship Diagram)
86. Нефункциональные требования (НФТ)
87. Архитектурные решения


📍 Сохрани себе — пригодится при знакомстве с архитектурой, микросервисами, API и подготовке к собеседованиям 😎


P.S. Есть что добавить? Пиши в комментарии!

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

✅ Компоненты архитектуры: шпаргалка для системных аналитиков и архитекторов ✅

Компонент — логически и технологически изолированный модуль архитектуры, реализующий строго определённые функции.

👉 обладает собственной кодовой базой и конфигурацией,
👉 разворачивается и масштабируется автономно,
👉 с другими модулями взаимодействует через формализованные интерфейсы.

При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, API или SDK.

Frontend-компоненты:

🖥 Сайты — информационные веб-страницы, без функций управления данными, только чтение. Дополнительно могут работать с заявками, управлением контентом (CMS), минималистичными ЛК пользователей и приемом платежей.

📱 Мобильные приложения — нативные (iOS, Android) или кросс‑платформенные (Flutter/React Native) клиенты с доступом к датчикам и оборудованию устройства, офлайн‑кэшем и пуш‑уведомлениями.

🖥 Веб-приложения — одно‑ или многостраничные приложения, работающие в браузере. Могут устанавливаться на сервера как независимо от Backend, так и включать в себя Backend (монолиты).

💻 Десктоп-приложения — устанавливаемые на компьютер программы, которые получают доступ к файловой системе, драйверам, оборудованию, и могут работать оффлайн. Например, редакторы фотографий, приложения банкоматов, кассы.

🔗 Виджеты — встраиваемые мини‑приложения (JS/iframe‑компоненты), добавляющие отдельную функцию в чужой интерфейс, без изменения кода и полного перезапуска той системы, куда они встраиваются.

Backend-компоненты:

🔹 Монолит — единое backend-приложение, где все логические модули системы организованы в одной общей кодовой базе. Деплоится и масштабируется только целиком, нельзя обновить только отдельный модуль внутри монолита. Обычно имеет только одну БД со всеми данными в ней.

🔹 Сервисы — логически выделенный компонент системы, отдельное backend-приложение средних размеров с ограниченным набором бизнес-логики. Деплоится и масштабируется независимо от остальных сервисов. Может иметь свою БД или использовать общую с другими сервисами.

🔹 Микросервисы — небольшой автономный сервис, владеющий узким бизнес‑контекстом, меньшим, чем у обычных сервисов, и (часто) со своей БД. Деплоится и масштабируется независимо от остальных сервисов.

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

🔹 Базы данных (БД) — отвечают за хранение текстовых данных в определенной структуре: реляционные (PostgreSQL, Oracle и другие), NoSQL, time‑series.

🔹 Файловое хранилище (ФХ) — компонент, отвечающий за долговременное хранение документов, фото, медиа и других файлов системы.

🔹 Брокеры сообщений — асинхронный обмен сообщениями (Kafka, RabbitMQ и другие).

🔹 Шина данных, ESB (Enterprise Service Bus) — интеграционная шина уровня предприятия, которая объединяет разнородные приложения через единый коммуникационный слой и «умную» посредническую логику. Типична для SOA архитектуры.

🩶 Внешние системы — платёжные системы, CRM, ЭДО и другие системы, с которыми нужна интеграция.

Hardware-компоненты:

🎥 Камеры
🖨 Принтеры, чековые терминалы
💳 Считыватели банковских карт
🎙 Микрофоны
📦 RFID/Barcode‑сканеры
🌡 IoT‑датчики (температура, влажность, движение).
и другие.



Используйте этот перечень как чек‑лист.

Он гарантирует, что в архитектурном описании не останется «слепых зон».
Каждый компонент должен быть явно показан на схеме — например, в нотации C4.

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

📚 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