Перейти к основному содержимому

Основы архитектуры

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Аналитику Тестировщику
Архитектору Инженеру

Play ITЗагрузка интерактивного демо…

Основы архитектуры​

Архитектура программного обеспечения — это фундамент, на котором строится любое приложение. Она определяет, как устроена система, из каких частей она состоит, как эти части взаимодействуют между собой и как они будут развиваться со временем.

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

Что такое архитектура ПО​

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

Архитектура отвечает на вопросы:

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

Архитектура — это то, что остаётся, когда убирают все детали реализации. Это уровень абстракции, позволяющий говорить о системе в целом, не погружаясь в строки кода.

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

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

Play ITЗагрузка интерактивного демо…

Интерфейс пользователя (Клиентское приложение)​

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

Виды клиентских приложений:

  • Веб-приложения: Работают в браузере, используют HTML, CSS и JavaScript. Не требуют установки на устройство пользователя.
  • Настольные приложения: Устанавливаются на компьютер под управлением Windows, macOS или Linux. Используют нативные технологии (например, .NET WPF, Java Swing).
  • Мобильные приложения: Работают на смартфонах и планшетах (iOS, Android). Разрабатываются с использованием Swift, Kotlin или кроссплатформенных фреймворков (Flutter — виджеты в Lab, React Native).
  • Терминальные клиенты: Текстовые интерфейсы для работы с сервером через SSH или консоль.

Функции компонента:

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

Сервер (Бэкенд)​

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

Задачи бэкенда:

  • Обработка бизнес-логики и правил принятия решений.
  • Аутентификация и авторизация пользователей.
  • Формирование ответов в формате JSON, XML или других протоколов.
  • Управление транзакциями и целостностью данных.
  • Интеграция с внешними сервисами и базами данных.

Технологический стек:

  • Языки — C#, Java, Python, Go, Node.js, PHP.
  • Фреймворки: ASP.NET Core, Spring Boot, Django, Express, Laravel.

Логика обработки данных​

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

Элементы логики:

  • Вычислительные операции: Математические расчеты, агрегация статистики.
  • Трансформация данных: Конвертация форматов, очистка мусорных данных, нормализация.
  • Бизнес-правила: Проверка условий (например, "если остаток товара меньше нуля, запретить заказ").
  • Обработка событий: Реакция на действия пользователя или системные события.

Бизнес-процессы​

Бизнес-процесс — это последовательность действий, выполняемых для достижения конкретной цели организации. В программной системе процесс реализуется как цепочка вызовов сервисов или шагов workflow (рабочего потока).

Характеристики бизнес-процессов:

  • Автоматизация: Замена ручного труда программными алгоритмами.
  • Оркестрация: Координация работы нескольких сервисов для выполнения задачи.
  • Отслеживание: Логирование каждого этапа процесса для аудита и анализа.
  • Гибкость: Возможность изменения последовательности шагов без переписывания кода.

Примеры процессов:

  • Оформление заказа: выбор товара -> корзина -> оплата -> доставка.
  • Регистрация сотрудника: ввод данных -> проверка уникальности -> создание записи -> рассылка приветствия.

API (Application Programming Interface)​

API служит мостом между различными частями системы или между системой и внешним миром. Он определяет правила передачи данных и команд.

Типы API:

  • REST API: Использует HTTP-методы (GET, POST, PUT, DELETE) и формат JSON. Стандарт де-факто для веб-сервисов.
  • SOAP API: Строгий протокол с использованием XML и WSDL. Часто применяется в корпоративных системах.
  • GraphQL: Позволяет клиенту запрашивать именно те данные, которые нужны, уменьшая объем передаваемой информации.
  • gRPC: Высокопроизводительный протокол на основе HTTP/2 и Protocol Buffers. Подходит для микросервисов.

Роль в архитектуре:

  • Стандартизация взаимодействия между фронтендом и бэкендом.
  • Предоставление доступа сторонним разработчикам к функционалу системы.
  • Изоляция изменений во внутренних сервисах от клиентов.

SDK (Software Development Kit) — отдельный слой: комплект библиотек и инструментов для создания приложения под платформу (мобильная ОС, .NET, облако). Готовое приложение по-прежнему вызывает API других сервисов; SDK лишь упрощает эти вызовы и сборку проекта. Таблица отличий, структура HTTP-запроса и примеры — в API — интерфейсы прикладного программирования.

Микросервисы​

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

Преимущества подхода:

  • Независимость: Сбой одного сервиса не останавливает всю систему.
  • Масштабируемость: Ресурсы выделяются только под нагрузку конкретного сервиса.
  • Разнородность технологий: Разные сервисы могут быть написаны на разных языках программирования.
  • Параллельная разработка: Команды работают над разными сервисами одновременно.

Примеры микросервисов:

  • Сервис аутентификации (управление пользователями).
  • Сервис каталога товаров.
  • Сервис обработки платежей.
  • Сервис уведомлений.

Базы данных (SQL / NoSQL)​

База данных хранит структурированную информацию, необходимую для работы системы.

Реляционные базы данных (SQL) используют таблицы со строгой схемой и связями между ними. Гарантируют целостность данных через транзакции.

  • Популярные реализации: PostgreSQL, MySQL, MS SQL Server, Oracle.
  • Подходящие задачи: Финансовые отчеты, учет заказов, сложные связи между сущностями.
  • Язык запросов: SQL (Structured Query Language).

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

  • Документоориентированные: MongoDB, Couchbase. Данные хранятся в формате JSON/BSON.
  • Ключ-значение: Redis, DynamoDB. Идеальны для кеширования и быстрых поисков по ID.
  • Графовые: Neo4j. Оптимизированы для поиска связей (социальные сети, рекомендации).
  • Колоночные: Cassandra, HBase. Эффективны для аналитики больших массивов данных.

Объектное хранилище файлов​

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

Ключевые особенности:

  • Масштабируемость: Возможность хранить петабайты данных без потери производительности.
  • Доступность: Данные доступны через HTTP/HTTPS API.
  • Надежность: Автоматическое реплицирование данных между узлами.
  • Примеры: Amazon S3, MinIO, Azure Blob Storage, Google Cloud Storage.

Использование:

  • Хранение аватарок пользователей.
  • Загрузка документов, прикрепленных к заявкам.
  • Сохранение медиа-контента для стриминга.

Кеширование​

Кеширование — это механизм временного хранения часто используемых данных в быстрой памяти. Цель — уменьшить количество обращений к медленным источникам (база данных, внешние API) и ускорить ответ пользователю.

Уровни кеширования:

  • Кеш на стороне клиента: Браузер или мобильное приложение сохраняют статику (картинки, скрипты).
  • Кеш на стороне сервера (In-Memory): Быстрое хранение результатов запросов в оперативной памяти (Redis, Memcached).
  • CDN (Content Delivery Network): Географически распределенные серверы для доставки статического контента ближе к пользователю.

Стратегии обновления:

  • Write-through: Данные пишутся сразу в базу и кеш.
  • Cache-aside: Приложение сначала проверяет кеш; если данных нет, загружает их из базы и сохраняет в кеш.
  • TTL (Time To Live): Автоматическое удаление данных из кеша через заданный промежуток времени.

Компоненты программного обеспечения​

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

  • Модулями — наборами классов, функций и ресурсов, объединённых общей задачей (например, модуль авторизации, модуль оплаты).
  • Классами — базовыми строительными блоками в объектно-ориентированных языках. Каждый класс инкапсулирует данные и поведение.
  • Базами данных — хранилищами структурированной информации. Они могут быть реляционными (PostgreSQL, MySQL), документными (MongoDB) или другими.
  • Сервисами — независимыми исполняемыми единицами, предоставляющими функциональность через интерфейсы (API).
  • Интерфейсами пользователя — частями системы, с которыми взаимодействует человек (веб-страницы, мобильные экраны, десктопные окна).

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

Взаимодействие компонентов системы​

Все перечисленные элементы объединяются в единый поток данных. Процесс начинается с действия пользователя и заканчивается сохранением результата или обновлением интерфейса.

| Шаг | Действие | Компоненты участвующие | Результат | | :--- | :--- | :--- | : | | 1 | Пользователь открывает страницу или нажимает кнопку | Клиентское приложение (Frontend) | Генерация HTTP-запроса | | 2 | Отправка запроса на сервер | API Gateway / Load Balancer | Маршрутизация запроса к нужному сервису | | 3 | Аутентификация и проверка прав | Сервис аутентификации (Backend) | Получение токена доступа или отказ | | 4 | Поиск необходимых данных | Бэкенд сервис + База данных (SQL/NoSQL) | Извлечение записей из хранилища | | 5 | Обработка бизнес-правил | Логика обработки данных | Трансформация сырых данных в готовые объекты | | 6 | Сохранение результатов | Сервис сохранения + Объектное хранилище | Запись файлов или обновление записей в БД | | 7 | Формирование ответа | API / Серверная часть | Возврат JSON/XML структуры клиенту | | 8 | Обновление интерфейса | Клиентское приложение | Отображение новой информации пользователю |

Клиентское приложение отправляет запросы через REST или GraphQL API. Сервер принимает эти запросы, проверяет их корректность и возвращает структурированный ответ. Если данные меняются динамически, используется механизм WebSocket для мгновенной передачи обновлений.

Взаимодействие Frontend и Backend​

Клиентское приложение отправляет запросы через REST или GraphQL API. Сервер принимает эти запросы, проверяет их корректность и возвращает структурированный ответ. Если данные меняются динамически, используется механизм WebSocket для мгновенной передачи обновлений.

Взаимодействие Backend и Базы данных​

Серверная логика использует ORM (Object-Relational Mapping) библиотеки или прямые драйверы для выполнения SQL-запросов. При необходимости система обращается к нескольким базам данных одновременно. Для повышения скорости чтения часто используется слой кеширования (Redis), который перехватывает повторяющиеся запросы.

Взаимодействие с Объектным хранищением​

При работе с файлами сервер не хранит сами файлы в базе данных. Вместо этого он сохраняет ссылку (URL) на объект в БД, а сам файл загружается в облачное хранилище. При скачивании файла сервер генерирует временную ссылку доступа.

Оркестрация микросервисов​

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

  1. Проверки наличия товара (Сервис инвентаризации).
  2. Списания средств (Сервис платежей).
  3. Создания записи о заказе (Сервис заказов).
  4. Отправки уведомления (Сервис уведомлений).

Координатором выступает оркестратор (например, Apache Kafka, RabbitMQ или специализированный сервис управления процессами), который управляет очередью сообщений и гарантирует выполнение всех шагов.

Роль кеширования в потоке​

Кеширование встраивается в критические точки пути данных. Когда пользователь запрашивает список товаров, система сначала смотрит в Redis. Если данные есть там, они возвращаются за миллисекунды. Если нет, данные запрашиваются из базы данных, сохраняются в кеш и затем отдаются пользователю. Это снижает нагрузку на базу данных при высокой посещаемости.

Связи между компонентами​

Связи определяют, как компоненты обмениваются информацией. Существуют два основных типа связей:

  • Синхронные — вызов одного компонента немедленно ожидает ответа от другого (например, HTTP-запрос к API).
  • Асинхронные — компонент отправляет сообщение и продолжает работу, не дожидаясь ответа (например, отправка события в очередь сообщений).

Связи могут быть:

  • Жёсткими — компонент напрямую зависит от конкретной реализации другого.
  • Гибкими — компонент взаимодействует через интерфейс или контракт, что позволяет заменять реализации без переписывания кода.

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

Принципы развития системы​

Архитектура должна поддерживать эволюцию. Система растёт — добавляются новые функции, меняются требования, появляются новые пользователи. Поэтому архитектура строится с учётом:

  • Масштабируемости — способности системы расти под нагрузкой.
  • Поддерживаемости — лёгкости внесения изменений и исправления ошибок.
  • Тестируемости — возможности проверить каждую часть независимо.
  • Разделяемости ответственности — каждый компонент делает одну вещь и делает её хорошо.

Эти принципы воплощаются в подходах SOLID, DRY, KISS, YAGNI — см. Принципы проектирования и SOLID в 4.07.

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

Для обеспечения стабильной работы системы архитекторы придерживаются ряда принципов.

Принцип изоляции​

Каждый компонент должен работать независимо от других. Сбой в одном модуле не должен приводить к падению всей системы. Достигается это через использование границ сервисов и механизмов защиты (Circuit Breaker).

Принцип прозрачности​

Система должна предоставлять понятные сообщения об ошибках и статусе операций. Логирование должно фиксировать все этапы обработки данных для возможности последующего анализа.

Принцип масштабируемости​

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

Принцип безопасности​

Все данные должны шифроваться при передаче (TLS/SSL). Доступ к ресурсам контролируется через механизмы аутентификации и авторизации. Уязвимости устраняются путем регулярного обновления зависимостей и проверки кода.

Принцип актуальности данных​

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

Как проектируют ПО​

Проектирование начинается с анализа требований. Аналитик собирает информацию от заказчика, пользователей, бизнеса. Затем архитектор:

  1. Определяет границы системы — что входит, а что нет.
  2. Выделяет основные компоненты и их роли.
  3. Выбирает архитектурный стиль (монолит, микросервисы, слоистая и т.д.).
  4. Продумывает потоки данных и точки интеграции.
  5. Формирует архитектурное описание — документ, содержащий диаграммы, решения, ограничения.

Проектирование — это итеративный процесс. Архитектор может создавать несколько вариантов, сравнивать их по критериям (стоимость, сложность, риски) и выбирать оптимальный.

Рассмотрим задачу "Загрузка профиля пользователя с аватаром".

  1. Клиент: Пользователь заходит в раздел "Профиль". Браузер отправляет GET-запрос /api/users/profile.
  2. API Gateway: Принимает запрос, проверяет токен JWT, перенаправляет его к сервису "Users".
  3. Сервис Users: Проверяет кеш Redis. Кеш пуст.
  4. База данных: Сервис делает SELECT-запрос к PostgreSQL для получения имени, email и ссылки на аватар.
  5. Логика: Сервис получает данные, формирует объект пользователя.
  6. Объектное хранилище: Сервис запрашивает файл изображения из MinIO/S3 по ссылке из БД.
  7. Ответ: Сервис возвращает JSON с данными профиля и URL картинки.
  8. Клиент: Браузер отображает текст профиля и загружает изображение с сервера хранилища.

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

Роль архитектора​

Архитектор ПО — это технический лидер, который видит систему целиком. Он:

  • Принимает ключевые технические решения.
  • Обеспечивает соответствие архитектуры бизнес-целям.
  • Консультирует разработчиков и аналитиков.
  • Следит за соблюдением архитектурных принципов.
  • Участвует в оценке рисков и планировании релизов.

Архитектор не пишет весь код, но он задаёт правила игры, по которым команда создаёт продукт.

Как выглядят сложные системы​

Сложная система — это не просто большой код. Это организованная структура, где:

  • Есть логические уровни — представление (UI), бизнес-логика, доступ к данным.
  • Есть физические уровни — клиентское устройство, веб-сервер, база данных, облачные сервисы.
  • Есть механизмы взаимодействия — REST API, очереди сообщений, gRPC, GraphQL.
  • Есть инфраструктурные элементы — балансировщики нагрузки, кэши, мониторинг, логирование.

Например, интернет-магазин может включать:

  • Фронтенд (React/Vue)
  • Бэкенд-сервисы (каталог, корзина, оплата)
  • Базу данных PostgreSQL
  • Систему уведомлений через RabbitMQ
  • Микросервис рекомендаций на Python
  • CDN для раздачи изображений

Всё это работает как единый организм благодаря продуманной архитектуре.

Как аналитики работают с архитектурой​

Аналитик получает от архитектора архитектурное описание — карту системы. На её основе он:

  • Декомпозирует общие задачи на конкретные пользовательские истории.
  • Определяет, какие компоненты затрагивает каждая функция.
  • Уточняет интерфейсы взаимодействия между модулями.
  • Формирует спецификации требований для разработчиков.

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

Как разработчики реализуют архитектуру​

Разработчик получает техническое задание, основанное на архитектуре. Он:

  • Создаёт модули и классы в соответствии с выделенными границами.
  • Реализует интерфейсы взаимодействия (API, DTO, события).
  • Соблюдает принципы проектирования, заданные архитектором.
  • Пишет тесты, проверяющие корректность работы компонента в системе.

Разработчик не решает, "куда положить логику оплаты" — это уже решено на архитектурном уровне. Его задача — качественно реализовать задуманное.

Монолит и микросервисы — вкратце​

Монолит — это единое приложение, где все компоненты (UI, логика, БД) собраны в один исполняемый файл или процесс. Преимущества — простота развёртывания, отладки, тестирования. Недостатки: сложно масштабировать отдельные части, риск "разрастания" кодовой базы.

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

Выбор между ними зависит от масштаба проекта, команды, требований к надёжности и скорости разработки.

Слоистая архитектура​

Слоистая (или многоуровневая) архитектура — один из самых распространённых стилей. Система делится на логические слои, каждый из которых имеет чёткую ответственность:

  1. Презентационный слой (Presentation) — отвечает за отображение данных и взаимодействие с пользователем.
  2. Слой бизнес-логики (Business Logic) — содержит правила, алгоритмы, процессы.
  3. Слой доступа к данным (Data Access) — управляет чтением и записью в хранилища.

Слои взаимодействуют только с соседними: презентация вызывает логику, логика — доступ к данным. Это упрощает тестирование и замену компонентов.

Логические и физические уровни​

  • Логические уровни — это абстракции внутри кода (слои, модули, пакеты). Они помогают организовать мышление разработчика.
  • Физические уровни — это реальные машины, контейнеры, процессы, на которых запускаются части системы.

Например, логический слой "бизнес-логика" может быть развёрнут на нескольких серверах (физических уровнях) для обеспечения отказоустойчивости.

Проектное решение​

Проектное решение — это конкретный выбор, сделанный в рамках архитектуры. Например:

  • Использовать PostgreSQL вместо MySQL.
  • Хранить файлы в MinIO, а не на диске сервера.
  • Реализовать авторизацию через OAuth 2.0.
  • Разделить модуль отчётов на отдельный микросервис.

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

Коннекторы и способы взаимодействия​

Коннекторы — это механизмы, через которые компоненты обмениваются данными. Они определяют:

  • Протокол (HTTP, TCP, AMQP)
  • Формат данных (JSON, XML, Protobuf)
  • Метод вызова (REST, SOAP, RPC)
  • Гарантии доставки (at-least-once, exactly-once)

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

Декомпозиция и объединение модулей​

Декомпозиция — это разбиение большой задачи на маленькие модули. Цель — сделать каждый модуль:

  • Понятным
  • Тестируемым
  • Переиспользуемым

Объединение происходит, когда модули работают вместе для выполнения сложной функции. Например, оформление заказа объединяет модули корзины, каталога, оплаты и доставки.

Правильная декомпозиция — ключ к поддерживаемой архитектуре.

Развертывание и внедрение​

Развёртывание — это процесс установки системы на серверы или в облако. Архитектура определяет:

  • Сколько экземпляров каждого компонента нужно запустить.
  • Как они будут обновляться (blue-green, канареечные релизы).
  • Как обеспечить отказоустойчивость.

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

Процессный, параллельный и клиент-серверный обмен​

  • Процессный обмен — данные передаются в рамках одного процесса (вызов метода, передача объекта).
  • Параллельный обмен — несколько потоков или процессов работают одновременно, используя общие ресурсы (очереди, блокировки).
  • Клиент-серверный обмен — один компонент (клиент) запрашивает данные у другого (сервера) по сети.

Архитектура выбирает подход в зависимости от требований к производительности, изоляции и распределённости.

Архитектурный шаблон (паттерн)​

Архитектурный паттерн — это проверенное решение типовой проблемы. Примеры:

  • MVC — разделение на модель, представление, контроллер.
  • CQRS — разделение команд и запросов.
  • Event Sourcing — хранение истории изменений вместо текущего состояния.
  • Strangler Fig — постепенная замена монолита микросервисами.

Паттерны — инструменты. Их можно комбинировать и адаптировать.

Архитектурное описание и его элементы​

Архитектурное описание — это документ, содержащий:

  • Архитектурные группы описаний — логические разделы (например, "инфраструктура", "безопасность", "интеграции").
  • Виды моделей — диаграммы компонентов, развёртывания, последовательностей.
  • Функциональную архитектуру — что система делает.
  • Поведенческую архитектуру — как она реагирует на события.
  • Временную архитектуру — как компоненты взаимодействуют во времени (тайминги, задержки, TTL).

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

Архитектурный подход и метод описания​

Архитектурный подход — это философия проектирования:

  • "Сначала масштабируемость"
  • "Максимальная простота"
  • "Безопасность превыше всего"

Метод описания — это способ фиксации архитектуры:

  • Диаграммы UML
  • C4-модель
  • ADR (Architectural Decision Records)
  • Простые текстовые документы с пояснениями

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

Функциональная, поведенческая и временная архитектура​

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

Функциональная архитектура​

Функциональная архитектура описывает, что система делает. Она фокусируется на бизнес-функциях, операциях и сервисах, которые предоставляет приложение. В этой модели:

  • Выделяются основные функциональные блоки (например, "управление пользователями", "обработка заказов").
  • Определяются входы и выходы каждого блока.
  • Указываются зависимости между функциями.

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

Пример: в интернет-магазине функциональная архитектура может включать:

  • Каталог товаров
  • Корзина покупок
  • Система оплаты
  • Личный кабинет
  • Уведомления

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

Поведенческая архитектура​

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

Эта архитектура отвечает на вопросы:

  • Что происходит, когда пользователь нажимает "Оформить заказ"?
  • Как система обрабатывает отказ платёжного шлюза?
  • Какие шаги выполняются при регистрации нового пользователя?

Для описания поведенческой архитектуры используются:

  • Диаграммы последовательностей (sequence diagrams)
  • Диаграммы состояний (state machines)
  • Диаграммы активности (activity diagrams)

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

Временная архитектура​

Временная архитектура описывает, как система ведёт себя во времени — задержки, тайминги, TTL (время жизни данных), периодичность задач, время отклика.

Эта архитектура учитывает:

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

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

Пример: в системе мониторинга датчиков температуры:

  • Данные с датчика отправляются каждые 5 секунд.
  • Если за 15 секунд нет сигнала — система генерирует аварию.
  • Агрегированные данные сохраняются на 30 дней.

Такие временные параметры становятся частью архитектурного контракта.

Архитектурные группы описаний и виды моделей​

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

  1. Структурная группа — компоненты, модули, зависимости.
  2. Поведенческая группа — сценарии, потоки, реакции.
  3. Развёртывания — физические серверы, контейнеры, сети.
  4. Безопасности — точки контроля доступа, шифрование, аудит.
  5. Производительности — ограничения по времени, пропускной способности.

Каждая группа содержит виды моделей:

  • Логическая модель — абстрактное представление без привязки к технологии.
  • Физическая модель — конкретные серверы, базы данных, облачные сервисы.
  • Концептуальная модель — высокоуровневое видение для заказчика.
  • Имплементационная модель — детали для разработчиков.

Хорошая архитектура покрывает все эти виды, чтобы каждый участник проекта получил нужную информацию.

Архитектурный подход и метод описания​

Архитектурный подход — это философия, которой следует команда. Например:

  • "Сначала безопасность" — все решения проверяются на соответствие требованиям безопасности.
  • "Максимальная простота" — предпочтение отдается минимальному количеству компонентов.
  • "Масштабируемость превыше всего" — даже в ущерб удобству разработки.

Метод описания — это инструмент фиксации архитектуры:

  • C4-модель — контекст, контейнеры, компоненты, код.
  • UML — универсальный язык моделирования.
  • ADR (Architectural Decision Records) — текстовые записи ключевых решений.
  • Простые схемы + пояснения — для небольших проектов.

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

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

В подборках​

Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:

Архитектура и проектирование ПО — Архитектура персонального компьютера, Платформы в IT, Программные платформы, Low-code и No-code платформы, Аутентификация и авторизация, Основы интеграционного взаимодействия — о разделе.

Системная аналитика — Платформенные решения в бизнесе, Аутентификация и авторизация, Корпоративное ПО, Основы интеграционного взаимодействия — о разделе, Программные платформы, Техническое письмо — о разделе.

Содержание