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

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как LEGO, только для взрослых)
✅ Способы взаимодействия компонентов (REST, RPC, события)
✅ Распределение ответственности между модулями
✅ Выбор технологического стека

Простой пример:
Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.

🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.

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

Пример компонентов:

• Authentication Service (следит, чтобы чужие не лезли)

• Notification Service (шлёт уведомления)

• Data Storage (хранит данные, очевидно)

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

Типы интерфейсов:

• REST API (классика жанра)

• Message Queue (асинхронные сообщения)

• RPC (удалённые вызовы)

• Database API (работа с данными)

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

Примеры связей:

• HTTP-соединения (веб-траффик)

• TCP/UDP сокеты (низкоуровневая связь)

• Message Brokers (Apache Kafka, RabbitMQ)

• Database connections (пул соединений с БД)

Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.

Примеры модулей:

• User Management Module (всё что касается пользователей)

• Payment Processing Module (платежи и транзакции)

• Analytics Module (метрики и отчёты)

Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.

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

• Order Service (управление заказами)

• Inventory Service (управление товарами)

• Billing Service (выставление счетов)

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

Типы хранилищ:

• Реляционные БД (PostgreSQL, MySQL)

• NoSQL (MongoDB, Redis)

• Файловые системы (S3, локальные диски)

• Кэши (Redis, Memcached)

SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".

Зачем нужны SLA:

• Понимание ожиданий от системы

• Планирование мощностей

• Определение критичности сервисов

• Основа для мониторинга

Практический пример:
Сервис авторизации должен:

• Отвечать за 100ms в 95% случаев

• Быть доступным 99.95% времени

• Выдерживать 1000 RPS

Чеклист для правильного проектирования:
✅ Каждый компонент имеет чёткую ответственность
✅ Интерфейсы документированы
✅ Связи (способы взаимодействия) определены
✅ Деление на сервисы произведено
✅ Способ хранения данных определен
✅ SLA определены и измеряемы
✅ Зависимости между компонентами минимальны

Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.

Почему архитектура без аналитика — это лотерея

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

Системный аналитик в архитектуре — это тот, кто ещё до первой строчки кода выясняет:

• кто по мосту пойдёт;

• когда он должен быть готов;

• какой ветер дует в регионе;

• и почему заказчик хочет на въезде логотип в стиле ар-деко.

Что делает аналитик:

• Формализует требования. Не «нужно быстро», а «время отклика — до 300 мс для 95% запросов».

• Собирает и декомпозирует требования: и бизнесовые, и технические.

• Описывает процессы и данные, чтобы разработчики понимали, с чем работают.

• Создаёт модели: ERD, BPMN, DFD, UML — чтобы было понятно и на митинге, и через год.

• Выявляет противоречия. Если в одном месте говорится «реестр должен быть публичным», а в другом — «данные должны быть защищены по ФЗ-152», аналитик не ждёт багов — он их предотвращает.

• Фиксирует ограничения: на инфраструктуру, бюджет, регуляторику.

Согласует архитектурные решения: чтобы бизнес понимал, почему микросервисы, а не монолит, и что это не «модно», а целесообразно.

Без него:

• Архитектор опирается на предположения.

• Команда упускает сценарии использования.

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

• В итоге — технический долг с первого релиза и недовольный бизнес

• И да, аналитик — не просто передатчик между бизнесом и технарями. Он переводчик с «хочу, чтобы было удобно» на «нужна интеграция с LDAP, SLA по логину — до 1 секунды».

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