Любая программа, которая прожила дольше пары месяцев, рано или поздно упирается в один и тот же вопрос: почему добавить крохотную функцию стало дольше, чем написать всё приложение с нуля. Отвечает на этот вопрос архитектура.
Разберём по шагам: что такое архитектура приложения, зачем её вообще проектируют, из каких частей состоит обычный сервис, чем монолит отличается от микросервисов и как выбрать подход, если у вас пока не интернет-банк, а первый пет-проект (учебное приложение, которое пишут для себя).
Если базовые вещи вроде запросов между программами пока звучат туманно, начните с материала «Что такое API простыми словами»: половина архитектурных разговоров крутится именно вокруг того, кто кому и в каком виде передаёт данные.
Ещё один полезный сосед по теме: принципы KISS, DRY, YAGNI и SOLID. Архитектура во многом состоит из них, только на этаж выше: там правила про строчки кода, здесь про целые куски системы.
Статья пригодится начинающим разработчикам, студентам и всем, кто собирается заказывать или принимать разработку. Если хочется системно освоить ремесло, загляните в нашу подборку курсов по программированию и IT: там больше полутора тысяч программ от коротких интенсивов до годовых. А если вы совсем в начале пути, есть отдельный разбор, как начать программировать с нуля.
CheckroiПодборка курсов программирования и IT1508 курсов • 65 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Что такое архитектура приложения простыми словами
Архитектура приложения — это набор решений о том, из каких частей состоит программа, кто за что отвечает и как эти части общаются между собой. Не код, а договорённости о коде. Не структура папок, хотя она обычно её отражает.
В книгах и вакансиях то же самое называют архитектурой программного обеспечения или коротко архитектурой ПО. Разницы между терминами нет, дальше по тексту они используются как синонимы.
Самая понятная аналогия здесь — планировка квартиры. Кухня отдельно, спальня отдельно, между ними коридор, вода приходит по трубам, электричество по проводам. Можно поставить плиту посреди спальни, и первое время всё будет работать. Проблемы начнутся, когда захочется поменять плиту или подселить соседа.
В программе то же самое. Пока приложение состоит из одного файла на двести строк, никакой архитектуры ему не нужно.
А потом файлов становится тридцать, и правят их трое. Появляются вопросы: где лежит проверка скидки, кто ходит в базу, что сломается, если поменять формат ответа.
Ключевая мысль. Архитектура нужна не программе, а людям вокруг неё. Компьютеру безразлично, лежит ли расчёт цены в обработчике кнопки или в отдельном модуле. Разница видна только тогда, когда кто-то приходит менять этот расчёт через полгода.
Чем архитектура отличается от паттерна проектирования
Эти два слова постоянно стоят рядом и постоянно путаются. Разница в масштабе.
Паттерн проектирования (типовое решение частой задачи в коде) отвечает на мелкий вопрос: как создать объект, как оповестить подписчиков об изменении, как подменить один алгоритм другим. Он живёт внутри одного модуля и занимает десятки строк.
Архитектура отвечает на крупный вопрос: сколько у нас независимых кусков, где проходят границы между ними, как они разговаривают, где хранятся данные, что произойдёт при отказе одного из них. Одна архитектурная ошибка стоит месяцев работы, одна ошибка в паттерне — часа.
Отсюда практическое следствие: MVC и MVVM, о которых постоянно спорят, честнее называть архитектурными паттернами. Они описывают устройство одного слоя (обычно интерфейса), но ничего не говорят о том, как ваши три сервиса переживут падение базы. Об этом ниже отдельный раздел.
Зачем нужна архитектура: четыре вещи, которые она экономит
Разговор про архитектуру часто превращается в перечисление красивых слов: масштабируемость, отказоустойчивость, поддерживаемость. Слова верные, только пустые, пока за ними не стоит понятная выгода.
Вот четыре понятные.
Время на правки. В приложении со внятными границами новая функция трогает один-два файла. В приложении без границ она трогает двенадцать, и половину из них разработчик видит впервые. Это самая заметная и самая дорогая разница.
Возможность работать командой. Пока границ нет, двое программистов постоянно правят одни и те же места и мешают друг другу. Когда система поделена на куски с понятной ответственностью, каждый забирает свой кусок и не толкается локтями.
Тестируемость. Если расчёт стоимости заказа лежит отдельно от кнопки и от базы, его можно проверить одним коротким тестом. Если он размазан по обработчику нажатия, для проверки придётся поднимать половину приложения.
Запас прочности под нагрузкой. Масштабируемость — это способность выдержать рост числа пользователей, добавив железа, а не переписав всё. Отказоустойчивость — способность продолжать работать, когда одна из частей умерла. Обе вещи закладываются заранее, задним числом их не прикрутить.
И обратная сторона: за отсутствие архитектуры платят техническим долгом. Это метафора займа: сегодня вы срезали угол и сделали быстрее, завтра платите процентами в виде лишних часов на каждую правку. Долг сам по себе нормален, ненормально только не замечать, что проценты растут.
Канал основателя Checkroi Вани Буявца3 700 человек читают мой Телеграм-канал про нейросетиСобрал промпты для Claude Code и ChatGPT, разборы ИИ-инструментов и лайфхаки по продвижению бизнеса в одном местеПрисоединитьсяИз чего состоит приложение: путь от кнопки до базы данных
Проще всего понять архитектуру, проследив один запрос целиком. Возьмём приложение доставки еды и нажмём кнопку «Заказать».
Клиент, сервер и что происходит между ними
Почти все современные приложения устроены по клиент-серверной схеме. Клиент — это то, что крутится на телефоне или в браузере пользователя: экраны, кнопки, анимации. Эту часть называют фронтендом. Сервер — программа на чужом компьютере в дата-центре, где лежат данные и принимаются настоящие решения. Это бэкенд.
Верхний уровень одинаков и для архитектуры веб-приложения, и для архитектуры мобильного приложения. Разница прячется в клиенте: у мобильного больше кода и данных живёт прямо на устройстве, поэтому там отдельно решают вопросы офлайна и синхронизации.
Вот что произойдёт после нажатия кнопки:
- Клиент собирает данные заказа и отправляет их на конкретный адрес сервера. Такой адрес называют эндпоинтом, а весь набор доступных адресов и правил обращения к ним — API.
- Запрос идёт по сети через сетевое соединение и попадает на сервер.
- Сервер проверяет, что пользователь авторизован, что ресторан открыт, что адрес в зоне доставки, и считает итоговую сумму со скидками.
- Сервер записывает заказ в базу данных — хранилище, которое переживёт перезапуск приложения. Часто рядом стоит кэш: быстрая память, куда кладут часто запрашиваемые данные, чтобы не дёргать базу по сто раз в секунду.
- Заодно он кладёт задачу «отправить пуш курьеру» в очередь сообщений: список отложенных дел, который разбирают отдельные программы. Пользователю не нужно ждать, пока курьер получит уведомление.
- Клиент получает ответ и рисует экран «Заказ принят».
Шесть шагов, четыре разных куска системы. Архитектура — это и есть решение о том, где проходят границы между этими кусками и что каждый из них имеет право делать.
Проверьте себя. Если вы можете рассказать этот путь про своё приложение и назвать, в каком файле живёт каждый шаг, архитектура у вас уже есть. Если на половине шагов ответ «где-то в том большом файле», её пока нет.
Три слоя внутри сервера
Серверную часть почти всегда режут на три слоя (группы кода с общей зоной ответственности). Названия у них плюс-минус стандартные:
| Слой | За что отвечает | Пример из доставки еды |
|---|---|---|
| Presentation (представление) | Принимает запросы, проверяет формат, отдаёт ответы | Обработчик эндпоинта /orders |
| Domain (бизнес-логика) | Правила предметной области, ради которых всё написано | Расчёт цены, проверка зоны доставки, применение промокода |
| Data (данные) | Чтение и запись в базу, обращение к чужим сервисам | Сохранение заказа, запрос к сервису оплаты |
Такое устройство называют разделением ответственности: каждый слой занимается своим и не лезет в чужое. Главное правило здесь одно: зависимости смотрят в одну сторону. Presentation знает про Domain, Domain знает про интерфейсы Data. В обратную сторону нельзя. Бизнес-логика не должна догадываться, лежат данные в PostgreSQL или в текстовом файле.
Зачем такая строгость. Поменяли базу, и переписывать пришлось только слой Data. Добавили мобильное приложение рядом с сайтом, и дописали к нему Presentation, а правила расчёта цены остались нетронутыми. Понадобилось проверить логику скидок, и тест написали на Domain без единого обращения к базе. Если интересно посмотреть на эту базу вживую, есть инструкция, как подключиться к базе данных в DBeaver.
Основные виды архитектуры приложений
Дальше про верхний уровень: на сколько независимых программ вообще делится система. Основные типы архитектуры приложений сводятся к четырём подходам.
Монолит
Монолитная архитектура — вся программа собирается и запускается как одно целое. Один проект, один процесс, одна база, одно развёртывание на сервер.
Монолит незаслуженно считают чем-то стыдным. На деле это правильный старт для подавляющего большинства проектов: проще писать, проще запускать, проще отлаживать, всё в одном месте.
Внутри монолита прекрасно живут слои и модули. Аккуратно нарезанный монолит на практике приятнее криво нарезанных микросервисов, и за последние годы это стало почти общим местом в индустрии.
Слабое место у него одно, зато растёт со временем: чем больше кода в одном мешке, тем сильнее части цепляются друг за друга. В какой-то момент правка в отчётах ломает оформление заказа, и никто не понимает почему.
Слоистая архитектура
Слоистая (она же многослойная или трёхуровневая) архитектура — тот самый пирог из presentation, domain и data, только объявленный явным законом проекта. Исторически она выросла из схемы девяностых «интерфейс, сервер приложений, база данных», и до сих пор остаётся рабочим стандартом корпоративной разработки.
Формально это не альтернатива монолиту, а способ его организовать. Монолит бывает слоистым, микросервис внутри тоже обычно слоистый. Путаница возникает из-за того, что в статьях эти вещи ставят в один список.
Микросервисы
Микросервисная архитектура — система разрезана на много маленьких самостоятельных программ. Каталог отдельно, заказы отдельно, оплата отдельно, уведомления отдельно. Каждый сервис живёт своей жизнью, обновляется отдельно и часто имеет собственную базу.
Что это даёт: команды не мешают друг другу, сервис оплаты можно разложить на двадцать копий под чёрную пятницу, не трогая остальное, падение уведомлений не роняет оформление заказа.
Чего это стоит: вместо одного приложения у вас теперь распределённая система. Сеть между сервисами иногда отказывает, данные разъезжаются, отладка превращается в расследование по логам пяти программ. Плюс нужны люди, которые умеют это обслуживать, и инфраструктура, которая это тянет. Плата немаленькая. Кто хочет разобраться в теме предметно, у нас есть подборка курсов по микросервисной архитектуре.
Событийная архитектура и serverless
Событийная архитектура — части системы не зовут друг друга напрямую, а обмениваются сообщениями через общую шину. Сервис заказов объявляет «заказ создан», а кто на это подпишется, ему безразлично. Так удобно строить всё, где на одно действие навешано много последствий: аналитика, бонусы, письма, склад.
Serverless (бессерверная архитектура) — код существует в виде отдельных функций, которые облако само запускает на время запроса и гасит после. Серверы никуда не делись, просто вы их не администрируете и платите за фактические вызовы. Хорошо для редких и неровных нагрузок, плохо для всего, что должно отвечать мгновенно и постоянно.
| Критерий | Монолит | Слоистая | Микросервисы | Событийная |
|---|---|---|---|---|
| Порог входа | Низкий | Низкий | Высокий | Высокий |
| Скорость старта | Максимальная | Высокая | Низкая | Низкая |
| Масштабирование | Целиком | Целиком | По частям | По частям |
| Устойчивость к отказам | Слабая | Слабая | Высокая | Высокая |
| Сложность отладки | Низкая | Низкая | Высокая | Очень высокая |
| Нужна команда | 1–5 человек | 2–10 человек | от 15 человек | от 15 человек |
| Стоимость инфраструктуры | Минимальная | Минимальная | Высокая | Высокая |
CheckroiПодборка курсов по микросервисной архитектуре21 курс • 7 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Какую архитектуру выбрать под свой проект
Два самых частых вопроса здесь звучат так: с чего начать проектирование и что выбрать, монолит или микросервисы. Универсального ответа нет, но есть довольно надёжная привязка к размеру задачи. Вот она в виде таблицы.
| Что вы делаете | Что брать | Почему |
|---|---|---|
| Пет-проект, учебное задание, скрипт | Один модуль без церемоний | Архитектура здесь стоит дороже самой задачи |
| MVP стартапа, первый продукт | Монолит со слоями | Скорость важнее всего, границы внутри уже заложены |
| Работающий бизнес, 2–10 разработчиков | Модульный монолит | Команды не мешают друг другу, инфраструктура ещё простая |
| Разные части растут с разной скоростью | Вынести узкие места в сервисы | Масштабируем только то, что упирается |
| Крупный продукт, много команд, высокая нагрузка | Микросервисы, событийный обмен | Независимые релизы и отказоустойчивость окупают сложность |
Отдельный частый вопрос: нужна ли архитектура маленькому проекту. Учебному скрипту — нет, проектирование обойдётся дороже самой задачи. Всему, что живёт дольше месяца и пишется не в одиночку, — да.
Правило, к которому индустрия пришла опытным путём: начинайте с самого простого варианта, который решает задачу, и усложняйте по мере появления настоящей боли. Разделить монолит на сервисы позже вполне посильно. Собрать двадцать разбежавшихся сервисов обратно намного тяжелее.
Если непонятно, что выбрать. Берите монолит с тремя слоями и аккуратными модулями внутри. Этот ответ подходит примерно девяти проектам из десяти и почти никогда не бывает грубой ошибкой.
MVC, MVVM и Clean Architecture: где тут архитектура, а где паттерн
Эти три названия чаще всего всплывают в вакансиях и на собеседованиях, поэтому разберём отдельно.
MVC (Model-View-Controller) делит код на три роли: Model хранит данные и правила, View показывает картинку, Controller принимает действия пользователя и связывает первых двух. Схема старая, понятная, лежит в основе множества веб-фреймворков.
MVVM (Model-View-ViewModel) устроен похоже, но вместо контроллера ставит ViewModel: она держит состояние экрана, а View сама подписывается на изменения и перерисовывается. Удобно там, где интерфейс живой и постоянно обновляется, поэтому прижилось в мобильной разработке. Рядом крутятся MVP и MVI с тем же смыслом и другой развесовкой обязанностей.
Clean Architecture (чистая архитектура) поднимается уровнем выше. Её главная идея: бизнес-правила в центре и ни от чего не зависят, а база, интерфейс и внешние сервисы — сменные детали по краям. Отсюда луковичные схемы с кольцами, которые все видели. За гибкость платят количеством кода: слоёв и интерфейсов становится заметно больше.
Что из этого следует практически. MVC и MVVM отвечают за устройство одного слоя, обычно интерфейсного. Clean Architecture задаёт правила для всего приложения. Ни одно из трёх названий не отвечает на вопрос про монолит и микросервисы, потому что это разговор о другом этаже системы.
CheckroiПодборка курсов для backend-разработчиков69 курсов • 20 школСравните цены, школы, программу и найдите выгодные предложения по обучениюСравнить→
Канал основателя Checkroi Вани БуявцаЗабирайте промпты и обучение по нейросетям в моём Телеграм-каналеБольше 3 700 человек уже применяют Claude Code, ChatGPT и другие нейросети в работе, учёбе, бизнесе и жизниПерейти в каналКак спроектировать архитектуру за шесть шагов
Проектирование выглядит менее страшно, если идти по порядку. Порядок примерно такой.
Шаг 1. Соберите требования. Функциональные (что приложение делает) и нефункциональные: сколько пользователей ожидается, за сколько миллисекунд должен приходить ответ, допустимо ли падать на пять минут в месяц, какие есть требования по данным и безопасности. Нефункциональные требования решают судьбу архитектуры сильнее функциональных, и именно их чаще всего забывают спросить. Обычно этим занимается системный аналитик, но в маленькой команде спрашивать придётся вам.
Шаг 2. Выпишите сущности предметной области. Заказ, пользователь, ресторан, курьер, промокод. Это будущие модули. Хороший признак: сущности берутся из языка заказчика, а не из названий технологий.
Шаг 3. Проведите границы. Соберите сущности в группы так, чтобы внутри группы связей было много, а между группами мало. В профессиональном разговоре это называют высоким зацеплением и низкой связанностью. Смысл простой: правка внутри одной коробки не должна заставлять открывать соседние.
Шаг 4. Опишите, как части общаются. Прямые вызовы внутри процесса, HTTP-запросы между сервисами, сообщения через очередь. Тут же решается, кто хранит какие данные и кто считается их владельцем.
Шаг 5. Нарисуйте схему. Достаточно прямоугольников и стрелок, хоть на бумаге. Схема, которую вы не можете нарисовать за пять минут, скорее всего слишком сложна для вашей задачи. Хороший ориентир по уровням детализации даёт модель C4.
Шаг 6. Запишите решения и причины. Одна страница текста в репозитории: что выбрали, какие были варианты, почему остановились на этом. Через год этот файл спасёт и вас, и новичка в команде от вопроса «зачем тут вообще очередь».
Пять ошибок, на которых спотыкаются новички
Ошибка 1: микросервисы на старте
Классика жанра — распределённая система с пятью сервисами для продукта, у которого десять пользователей. Команда получает всю сложность распределённых систем и ни одного её преимущества, потому что масштабировать пока нечего. Это называют оверинжинирингом: решением задач, которых у вас нет.
Ошибка 2: слои ради слоёв
Вторая крайность того же порядка. Чтобы добавить одно поле, разработчик правит семь файлов в пяти слоях, и каждый из них просто передаёт данные дальше. Слой оправдан, когда он что-то делает: проверяет, преобразует, скрывает деталь. Слой-курьер стоит убрать.
Ошибка 3: копипаст чужой схемы
Архитектура крупного маркетплейса решает проблемы крупного маркетплейса: сотни разработчиков, миллионы запросов, требования регуляторов. В проекте на трёх человек она даёт только накладные расходы. Смотреть чужие решения полезно, а копировать целиком почти всегда бессмысленно.
Ошибка 4: бизнес-логика внутри интерфейса
Самая частая и самая тихая ошибка. Расчёт скидки живёт прямо в обработчике нажатия кнопки. Работает отлично ровно до момента, когда появляется мобильное приложение или админка, и выясняется, что логику надо копировать. Дальше две копии расходятся, и скидка в вебе перестаёт совпадать со скидкой в приложении.
Ошибка 5: «потом отрефакторим»
Долг становится проблемой не тогда, когда появляется, а тогда, когда его перестают считать. Здоровая практика: держать список известных срезанных углов и отдавать долгам понемногу в каждой итерации. Раз в год объявлять большой рефакторинг (переписывание кода без изменения того, что он делает) обычно не получается ни у кого.
Семь признаков, что с архитектурой всё в порядке
Короткий чек-лист, по которому можно проверить свой проект прямо сейчас.
- Новую функцию удаётся описать одним предложением вида «трогаем такой-то модуль». Если объяснение занимает абзац, границы размыты.
- Бизнес-правила можно прочитать без базы и интерфейса. Есть место, где написано, как считается цена, и там нет SQL-запросов.
- Замена внешнего сервиса не задевает половину кода. Сменить платёжного провайдера — это правка в одном модуле.
- Тесты пишутся без поднятия всего приложения. Если для проверки скидки нужна живая база, слои склеены.
- Новый человек начинает приносить пользу за неделю. Структура проекта читается сама, без часового рассказа старожила.
- Понятно, что произойдёт при отказе каждой части. Хотя бы на уровне «упадёт вот это, а заказы продолжат оформляться».
- Схема рисуется за пять минут по памяти. Любым разработчиком команды, а не только автором.
Пять пунктов из семи — нормальное состояние живого проекта. Меньше трёх — повод сесть и разобрать систему на бумаге, пока правки ещё стоят часы, а не недели.
Кто отвечает за архитектуру: джун, тимлид или архитектор ПО
Формально в больших компаниях есть отдельная роль — архитектор ПО. За качество архитектуры ПО в продукте отвечает именно он: выбирает подход, следит за границами между системами, принимает решения про технологии и объясняет их командам. Приходят в эту роль обычно из разработки после многих лет практики, поэтому вакансий на неё немного, а требования высокие.
В компаниях поменьше архитектурой занимается тимлид или самый опытный разработчик, а решения принимаются на общем обсуждении. В совсем маленьких командах их принимает тот, кто пишет код. Верхнеуровневый надзор за этим обычно остаётся у технического директора.
Зарплата архитектора ПО обычно заметно выше, чем у рядового разработчика, потому что роль редкая и требует многолетнего опыта. Быстрого входа в неё нет ни у кого.
Начинающему разработчику важно понимать вот что: архитектурные решения вы принимаете с первого дня, даже если вас об этом никто не просил. Куда положить функцию, вынести ли повторяющийся код, обращаться ли к базе прямо из обработчика — это всё оно. На собеседовании джуна не спросят, как построить систему на миллион пользователей, но вполне могут спросить, зачем нужны слои и чем монолит отличается от микросервисов.
Где научиться проектировать архитектуру
Архитектуру тяжело выучить в отрыве от практики: она вырастает из опыта, когда несколько раз наступишь на последствия своих решений. Но теоретическая база сокращает путь заметно, потому что многие грабли уже описаны до нас.
Рабочий порядок обучения такой. Сначала уверенно писать код на одном языке. Потом разобраться с базами данных и API. Потом читать про принципы проектирования и сознательно раскладывать свои учебные проекты по слоям. Микросервисы и распределённые системы имеет смысл трогать после первого года коммерческой работы.
Отдельных программ ровно про архитектуру программного обеспечения на рынке мало: тема обычно идёт разделом внутри курсов веб-разработки и бэкенда. Это нормально, потому что в отрыве от языка и базы данных проектирование учить бессмысленно.
Если хочется идти по выстроенной программе, а не собирать знания кусками, посмотрите подборку курсов ниже. Мы собрали программы разных школ в одном месте, чтобы можно было сравнить длительность, цену и наполнение, не открывая двадцать вкладок.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Нейросети для рабочих задач Перейти на сайт курса |  Skillbox | 31 290 ₽ | 2608 ₽/мес. | 1 месяц | Обзор курса |
| Нейросети. Практический курс Перейти на сайт курса | Skillbox | 74 900 ₽ | 6242 ₽/мес. | 3 месяца | Обзор курса |
| Программирование для анализа данных |  Skypro | 134 640 ₽ | 5500 ₽/мес. | 12 месяцев | Обзор курса |
| Frontend-разработчик с нуля Перейти на сайт курса |  Нетология | 113 400 ₽ | 5385 ₽/мес. | 10 месяцев | Обзор курса |
| Профессия «Python-разработчик» Перейти на сайт курса | Skillbox | 157 335 ₽ | 5987 ₽/мес. | 10 месяцев | Обзор курса |
| Профессия «Fullstack-разработчик на PHP» Перейти на сайт курса | Skillbox | 166 715 ₽ | 5378 ₽/мес. | 12 месяцев | Обзор курса |
| Fullstack-разработчик на Python Перейти на сайт курса | Нетология | 175 800 ₽ | 7125 ₽/мес. | 21 месяц | Обзор курса |
| Профессия «Java-разработчик с нуля» Перейти на сайт курса | Нетология | 131 700 ₽ | 5625 ₽/мес. | 11 месяцев | Обзор курса |
| Профессия «Разработчик игр на Unity с нуля» Перейти на сайт курса | Skillbox | 130 521 ₽ | 3679 ₽/мес. | 10 месяцев | Обзор курса |
| PHP-разработчик с нуля до PRO Перейти на сайт курса | Skillbox | 114 876 ₽ | 4176 ₽/мес. | 7 месяцев | Обзор курса |
Больше программ — в полном каталоге курсов по программированию и IT
Отдельно стоит посмотреть направление курсов backend-разработки: архитектурные темы почти всегда живут именно там. А чтобы понимать, куда всё это ведёт, пригодятся разборы профессии бэкенд-разработчика и пути от первого API до оффера.
