Паттерн — это имя для ответа, а не правило

В шахматах ты не изобретаешь дебют каждую партию. Ты узнаёшь: «это сицилианская защита» — и уже знаешь, куда она обычно ведёт.

Архитектурный паттерн (architectural pattern) = повторяющаяся проблема + проверенная форма решения + известная цена. Когда ты говоришь «сервисам нужно реагировать на то, что происходит в другом месте», это уже решённая и названная задача — паттерн Event-driven architecture. Знать каталог — значит перестать изобретать и начать выбирать.

Архитектурные паттерны ≠ паттерны проектирования

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

Паттерны проектирования (design patterns) — Factory, Observer, Strategy — живут внутри кода одного модуля. Архитектурные паттерны решают, какие большие «коробки» есть в системе и какие линии между ними: что разворачивается отдельно, кто с кем разговаривает, где живут данные. Этот курс — про планировки, а не про мебель.

Карта: 17 паттернов в шести группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

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

Как читать каждый паттерн

Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

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

Layered Architecture — слоистая архитектура

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

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

Modular Monolith — модульный монолит

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

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

MVC / MVVM — держать экран подальше от мозгов

Театр: сценарий, актёры с режиссёром и сцена со светом — разные работы. Декорации меняют, не переписывая пьесу.

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

Hexagonal Architecture — порты и адаптеры

Игровая консоль со стандартными разъёмами. Игре всё равно, что воткнули — геймпад, руль или аркадный стик; она просто читает «ввод».

Ядро с бизнес-логикой объявляет порты (ports) — интерфейсы вроде «сохранить заказ» или «списать деньги». Снаружи адаптеры (adapters) реализуют эти порты под конкретную технологию. Driving adapters вызывают ядро (HTTP API, CLI, тесты), driven adapters вызываются ядром (база, платёжка, почта).

Clean / Onion Architecture — зависимости смотрят внутрь

Луковица: сердцевина в центре, слои вокруг. Шелуху можно снять, не повредив сердцевину, — а сердцевина от шелухи не зависит.

Тот же принцип в виде кругов. В центре сущности (entities), вокруг сценарии (use cases), дальше адаптеры, снаружи фреймворки и база. Главное правило — dependency rule: каждая стрелка зависимости смотрит к центру.

Microservices — микросервисы

Фуд-корт: у каждой точки своя кухня, меню и касса. На пиццу налегли — ставят двух поваров; салатной это не нужно.

Система разбита на маленькие сервисы (services): каждый владеет одной бизнес-способностью и своей базой, разворачивается и масштабируется отдельно. Сервисы общаются по сети — HTTP или через шину сообщений.

Serverless — функции по требованию

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

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

Request–Response — спросить и ждать

Заказ у стойки: спросил, стоишь, получил кофе — только потом идёшь дальше.

Клиент отправляет запрос (request) и ждёт ответ (response). Это синхронное общение: REST, gRPC, запрос в базу.

Event-driven Architecture — объяви, а слушатели отреагируют

Редакция новостей: вышла новость — спорт, погода и реклама реагируют сами. Диктор их не ждёт и даже не знает, кто слушает.

Компонент не вызывает других, а публикует событие (event) — факт, который уже случился: «OrderPlaced». Кому интересно, тот подписан и реагирует. Два варианта: broker (события расходятся свободно) и mediator (координатор ведёт шаги по порядку).

Message Queue и Pub/Sub — почта между частями

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

Очередь сообщений (message queue) или брокер pub/sub встаёт между отправителем и получателем, чтобы им не нужно было быть онлайн одновременно. В очереди одно сообщение берёт один worker; в pub/sub одно сообщение получают все подписчики.

Pipe-and-Filter — конвейер для данных

Линия розлива: помыть, налить, закрыть, наклеить этикетку. Каждая станция делает одно и передаёт бутылку дальше.

Данные текут через цепочку независимых шагов — фильтров (filters), соединённых трубами (pipes). Каждый фильтр делает одно преобразование.

CQRS — раздельные модели записи и чтения

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

CQRS (Command Query Responsibility Segregation) разделяет модель записи — команды (commands), которые меняют данные, — и модель чтения — запросы (queries), которые их достают. Каждую можно оптимизировать и масштабировать отдельно.

Event Sourcing — хранить историю, а не состояние

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

Вместо того чтобы перезаписывать текущее состояние, ты хранишь поток событий (event log), только дописывая в конец. Текущее состояние получается проигрыванием (replay) событий.

Saga — длинная операция, которую можно отмотать

Бронируешь поездку: рейс, отель, машина. Машина сорвалась — отменяешь отель и рейс. Единой кнопки «отменить всё» нет, отматываешь по шагу.

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

Microkernel — маленькое ядро и плагины

Дрель: один мотор и дюжина насадок. Дрель та же — меняешь насадку под задачу.

Минимальное ядро (core) даёт основу, всё остальное приходит плагинами (plugins), которые подключаются к ядру и не зависят друг от друга.

Space-based Architecture — данные в памяти без узкого места

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

Когда единственная база становится узким местом под огромной нагрузкой, работу делят много processing units, каждый держит данные в памяти. Память синхронизируется между ними (data grid), а в базу данные пишутся позже, асинхронно.

Peer-to-Peer — без центра

Ужин в складчину: каждый и повар, и гость. Ни ресторана, ни официанта — группа кормит себя сама.

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

Паттерны связаны между собой

Дом сразу использует несущие стены, водопровод и проводку — не «один истинный паттерн строительства».

Паттерны не живут поодиночке. Модульный монолит вырастает в микросервисы; микросервисам нужны события, очереди и саги; Hexagonal и Clean — одна идея; CQRS и Event Sourcing ходят парой.

Реальная система может быть модульным монолитом снаружи, Clean Architecture в каждом модуле, Request–Response для интерфейса, событиями для медленных побочных эффектов и очередью перед тяжёлой задачей. Вопрос не «какой паттерн», а «какие паттерны и где».

Начинай с самой простой формы

Под домик не заливают фундамент для стадиона.

Почти любая система должна начинаться как Modular Monolith и заслуживать свою сложность. Microservices, CQRS, Event Sourcing, Space-based — ответы на проблемы масштаба и размера команды, которых у тебя может никогда не быть. Самая дешёвая распределённая система — та, которую ты не построил.