Архитектура приложения: что это, как построить, ключевые методы и принципы

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

Что такое архитектура ПО и для чего она нужна

Архитектура ПО описывает устройство системы на высоком уровне: из каких крупных частей она состоит, как они взаимодействуют, где находятся данные и какие ограничения нужно учитывать.

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

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

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

Основные виды и особенности архитектур приложений

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

Монолитная архитектура

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

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

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

Слоистая, или N-tier-архитектура

Здесь систему делят на уровни: например, интерфейс, бизнес-логику и слой работы с данными.

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

Изменение страницы оформления заказа в такой системе не должно заставлять разработчика переписывать расчёт скидки. В N-tier отдельные уровни могут быть разделены и физически. Microsoft отмечает, что это помогает масштабировать и изолировать части системы, хотя дополнительные сетевые вызовы увеличивают задержки.

Микросервисная архитектура

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

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

Микросервисы хорошо решают проблемы большой системы и нескольких независимых команд.

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

Событийно-ориентированная архитектура

Некоторые процессы удобнее строить не через прямую цепочку вызовов, а через события.

После оплаты заказа сервис платежей публикует событие «заказ оплачен». Его получают склад, система уведомлений и модуль лояльности. Платёжному сервису при этом не нужно знать, что именно они сделают дальше.

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

Клиент-серверная архитектура

Это не альтернатива монолиту или микросервисам, а другой уровень описания.

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

Serverless

Serverless полезен там, где функции запускаются по событию, а нагрузка меняется скачками.

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

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

Какие команды создают приложения: ключевые роли

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

Допустим, интернет-магазин решил добавить доставку в день заказа. Product Manager задаёт бизнес-цель и приоритет: функция должна появиться к началу высокого сезона. Бизнес-аналитик описывает процесс – когда такая доставка доступна, какие есть ограничения и что видит пользователь.

Системный аналитик переводит этот процесс на технический уровень: откуда получать свободные слоты, какие статусы передавать курьерской системе, что делать при отмене заказа.

После этого архитектор или технический лидер определяет, какие компоненты придётся изменить и нужен ли новый сервис. Backend-разработчики реализуют серверную логику и API, frontend- или mobile-команда добавляет сценарий в интерфейс. QA проверяет обычные и аварийные ситуации, DevOps или SRE настраивает развёртывание, мониторинг и ресурсы. Если функция затрагивает платежи или персональные данные, подключается специалист по безопасности.

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

Как построить архитектуру приложения

Проектирование удобнее начинать не с выбора технологий, а с требований и ограничений продукта. Kubernetes, Kafka или микросервисы сами по себе систему лучше не делают.

1. Описать ключевые сценарии

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

Уже здесь видно, какие процессы критичны и где приложение зависит от внешних сервисов.

2. Зафиксировать нефункциональные требования

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

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

3. Провести границы между модулями

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

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

4. Спроектировать данные

Нужно определить основные сущности, связи между ними и владельцев данных. Для заказа это пользователь, товары, цена, статус, адрес, способ оплаты и доставки.

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

5. Определить взаимодействие компонентов

Не каждый процесс требует мгновенного ответа.

Проверка промокода при оформлении заказа, скорее всего, должна происходить синхронно. Отправку письма после оплаты можно сделать асинхронной.

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

6. Продумать безопасность и эксплуатацию

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

Одновременно стоит продумать эксплуатацию. Если новая версия оформления заказа после релиза начала выдавать ошибки, команда должна быстро это увидеть и иметь возможность откатить обновление. Для этого заранее закладывают логи, метрики, трассировку запросов и процедуру восстановления после сбоя.

7. Проверить рискованные места

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

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

Инструменты и методы архитектурного проектирования

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

C4 Model

C4 показывает систему на нескольких уровнях: контекст, контейнеры, компоненты и код.

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

Такую схему проще читать, чем одну огромную диаграмму со всеми классами и таблицами.

UML

UML используют там, где нужно показать конкретный вид взаимодействия.

Sequence diagram подходит для сценария оплаты: клиент → backend → платёжный провайдер → сервис заказов. Component diagram показывает зависимости между крупными частями, deployment diagram – где они физически работают, а class diagram помогает описать структуру классов и их связи.

BPMN и ER-диаграммы

BPMN полезен, когда технической команде нужно понять сам бизнес-процесс. Например, как проходит возврат: кто создаёт заявку, когда требуется проверка менеджера и в какой момент запускается возврат денег.

ER-диаграмма показывает модель данных – сущности и связи между ними.

API-контракты

Если компоненты работают через API, договорённость должна быть формальной. В спецификации фиксируют методы, параметры, форматы запросов и ответов, коды ошибок и правила авторизации.

Для HTTP API часто используют OpenAPI. Контракт позволяет frontend- и backend-командам двигаться параллельно и меньше зависеть от внутренних деталей реализации друг друга.

ADR

Architecture Decision Record фиксирует не устройство всей системы, а конкретное решение и причину его принятия.

Например: «Оставляем модульный монолит, потому что продукт обслуживает одна команда и независимое масштабирование модулей пока не требуется».

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

Proof of concept

Если архитектурное решение связано с большой неопределённостью, команда может собрать небольшой прототип.

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

Как не потерять данные при создании приложения

Во время разработки теряются не только файлы. Гораздо чаще теряется контекст.

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

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

В бэклоге полезно фиксировать не только разработку отдельных функций, но и работы по сдаче этапов: согласование схемы данных, подготовку API, аудит безопасности, миграции, тестирование и обновление документации. Тогда видно, кто отвечает за конкретный участок и к какому сроку он должен быть завершён.

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

• глоссарий терминов бизнес-логики;

• описание архитектуры приложения;

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

• список процедур и функций бизнес-логики с принимаемыми параметрами;

• спецификации API;

• модель данных;

• руководство пользователя;

• инструкции по развёртыванию и восстановлению;

• журнал ключевых архитектурных решений.

Документацию нужно связывать с изменениями продукта. Если команда переработала API или перенесла часть логики в отдельный сервис, старая схема должна обновиться вместе с задачей. Иначе база знаний быстро становится архивом документов, которым никто не доверяет.

Отдельно стоит защищать данные самого приложения: делать резервные копии, ограничивать доступ, вести журналирование и регулярно проверять восстановление. Наличие бэкапа ещё не означает, что из него действительно получится поднять рабочую систему.

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

Используйте инструменты TEAMLY, чтобы управлять рабочими процессами

Записывайтесь на онлайн-презентацию! Продемонстрируем интерфейс и все возможности платформы

Получить демо