Компонент — логически и технологически изолированный модуль архитектуры, реализующий строго определённые функции.
👉 обладает собственной кодовой базой и конфигурацией,
👉 разворачивается и масштабируется автономно,
👉 с другими модулями взаимодействует через формализованные интерфейсы.
При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, 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