Системная архитектура

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

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

Какие вопросы она решает

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

Пример: схема интернет-магазина

Браузер → CDN (картинки, стили)
        → nginx → PHP-FPM (1С-Битрикс) → MariaDB
                    ├→ Redis (кеш, сессии)
                    ├→ 1С (каталог и остатки, обмен раз в час)
                    ├→ платёжный шлюз (оплата, уведомления)
                    └→ CRM (заявки через вебхук)

Даже такая простая схема отвечает на важные вопросы. Если 1С недоступна, магазин продолжает работать на последних выгруженных остатках. Если CRM не принимает заявки, их нужно сохранять и отправлять повторно. Кеш снимает нагрузку с базы при наплыве посетителей.

Как фиксируют решения

Схему системы удобно рисовать по модели C4: от общего контекста к контейнерам, компонентам и коду. Отдельные решения записывают в коротких документах ADR: что выбрали, какие были варианты и почему отказались от остальных. Через год такой документ объяснит новому разработчику, почему всё устроено именно так, и сэкономит спор о том, не переписать ли всё заново. Проектирование архитектуры — первый этап заказной разработки, от него зависят сроки и стоимость дальнейших работ.