Уровень 5 (занятие) · лекция · 3 октября, 11:10
Архитектурные стили и как выбирать. C4 и ADR
Какие бывают архитектурные стили и на какой вопрос отвечает каждый, как выбрать стиль под свои требования, как нарисовать систему в C4 и записать решение в ADR.
Курс «Проектирование веб-приложений» · 2026/27
Архитектурные стили и как выбирать
Из каких стилей выбирают, как выбрать под свои требования, как нарисовать систему в C4 и записать решение в ADR
Где мы
- Требования к системе есть: бизнес, функциональные, нефункциональные с числами
- Идёт этап RAT-PoC, сегодня первый чекпоинт
- На защите 17 октября: C4 уровней 1 и 2 и объяснённый выбор архитектуры
- Сегодня: стили, выбор, C4 и ADR
Архитектура — это решения, которые хочется принять правильно в самом начале проекта
Architecture is the decisions that you wish you could get right early in a project
Повторим: фронтенд-бэкенд архитектура
Сервер
Бэкенд сервер


Браузер
ПК
База данных
Файлы







Фронтенд сервер
Фронтенд
Стиль отвечает на один из вопросов
- Где выполняется логика? — толстый или тонкий клиент
- Как связаны узлы? — клиент-сервер или P2P
- Что развёртываем? — монолит, модульный монолит, микросервисы
- Как организован код? — слои, микроядро
- Как общаются части? — прямые вызовы или события
Реальная система — сочетание ответов: например, слоистый монолит с очередью событий
Клиент и сервер
Клиент-серверная архитектура
Клиент-серверная архитектура — это модель взаимодействия компонентов в распределенной системе, где задачи разделяются между двумя основными сторонами: клиентом и сервером. В этой архитектуре клиент запрашивает данные или услуги у сервера, а сервер предоставляет их, обрабатывая запросы и управляя ресурсами.
ссылка

Какие альтернативы?

Какие альтернативы?

P2P

Peer-to-peer - это архитектура передачи данных, основанная на идее равноправия всех участников сети. В сети отсутствуют выделенные серверы. В отличие от традиционных сетей, каждый из участников является как клиентом, так и сервером.
ссылка
Примеры
●BitTorrent протокол

Примеры
●Blockchain

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

“Толстый” клиент (Thick/Fat Client)


“Толстый” клиент — это приложение, которое выполняет основную часть обработки данных на стороне пользователя, обращаясь к серверу преимущественно для хранения данных или синхронизации. Такие клиенты способны работать автономно, без постоянного подключения к сети.
“Толстый” клиент (Thick/Fat Client)

Примеры


●PWA с офлайн-режимом: заметки, карты с загруженными регионами
●Desktop приложения: Electron (VS Code, Discord)
Примеры


“Тонкий” клиент (Thin Client)


“Тонкий” клиент — это клиентское приложение, которое берет на себя минимальные задачи, такие как отображение данных и отправка запросов на сервер. Вся бизнес-логика, обработка данных и выполнение операций происходят на сервере.
“Тонкий” клиент (Thin Client)

“Тонкий” клиент (Thin Client)

“Тонкий” клиент (Thin Client)
●Server-Side Rendering (SSR): рендеринг на сервере, примеры: Wikipedia
●Multi-Page Applications (MPA): классические веб-сайты

Куда отнесем?

SPA
SPA (Single Page Application) — это веб-приложение, которое загружает одну HTML-страницу и динамически обновляет её содержимое по мере взаимодействия пользователя с приложением, без полной перезагрузки страницы.

SPA
SPA (Single Page Application) — это веб-приложение, которое загружает одну HTML-страницу и динамически обновляет её содержимое по мере взаимодействия пользователя с приложением, без полной перезагрузки страницы.
и туда и туда - гибрид

Пример SPA


Монолитная архитектура
Монолитная архитектура — это архитектурный подход, при котором все компоненты веб-приложения собираются и развёртываются вместе, одной единицей.


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

Преимущества монолита
Преимущества монолита
➕Простота разработки - единая кодовая база, простое тестирование
➕Простота развертывания - один артефакт для деплоя
➕Производительность - отсутствие сетевых вызовов между компонентами
➕Отладка - легче отследить выполнение кода
➕Транзакции - ACID-транзакции в рамках одной БД
Недостатки монолита
Недостатки монолита
−Сложность масштабирования отдельных компонентов
−Технологическая связанность
−Риск каскадных отказов
−Сложность работы больших команд

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

Ключевые принципы
Ключевые принципы
1.Single Responsibility - один сервис = одна бизнес-функция
2.Decentralized Governance - независимые технологии и команды
3.Fault Isolation - отказ одного сервиса не должен ронять другие
4.Independent Deployment - возможность деплоить сервисы отдельно
5.Data Decentralization - каждый сервис управляет своими данными
Преимущества микросервисов
Преимущества микросервисов
➕Масштабируемость - независимое масштабирование компонентов
➕Технологическое разнообразие - разные технологии для разных сервисов
➕Независимость команд - команды могут работать автономно
➕Отказоустойчивость - изоляция отказов, если её спроектировать
➕Быстрая разработка - параллельная разработка сервисов
Недостатки микросервисов
Недостатки микросервисов
−Сложность - больше компонентов для управления
−Сетевая задержка - вызовы между сервисами
−Распределенные транзакции - сложность обеспечения консистентности
−Мониторинг - сложность отслеживания состояния системы
−DevOps требования - нужна зрелая DevOps-культура
Организация, которая проектирует систему, получает систему, повторяющую структуру своих коммуникаций
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure
Serverless
Serverless - это модель выполнения программного кода, при которой функции создаются и выполняются по требованию в управляемой среде облачного провайдера, без необходимости управления серверами или инфраструктурой.

Как организован код и как общаются части
Слоистая архитектура — это паттерн архитектуры, в котором система разделяется на уровни (или слои), каждый из которых выполняет определенную функцию и взаимодействует с другими уровнями через четко определенные интерфейсы. Этот подход упрощает разработку, тестирование и поддержку системы, так как каждый слой несет свою ответственность и может развиваться независимо.
ссылка
Слоистая архитектура (Layered Architecture)

Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Концепция изолированных слоев (Layers of isolation)

Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Концепция изолированных слоев (Layers of isolation)

Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Событийно-ориентированная архитектура — это популярный распределённый асинхронный шаблон архитектуры, используемый для создания приложений с высокой степенью масштабируемости.
Состоит из двух частей: топология посредника (mediator) и топология брокера (broker)
ссылка
Событийно-ориентированная архитектура
(Event-Driven Architecture)
Топология посредника

Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Топология брокера

Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Микроядерная архитектуры (второе название — паттерн архитектуры подключаемых модулей, плагинная архитектура) - паттерн архитектуры, который позволяет добавлять дополнительные функции приложения в качестве подключаемых модулей к основному приложению, обеспечивая расширяемость, а также разделение и изоляцию функций.
Микроядерная архитектура (Microkernel architecture)



Схема: Mark Richards,
«Software Architecture Patterns»,
O’Reilly, 2015
Как выбирать
От требований к стилю
- Начинаем с нефункциональных требований с третьей лекции
- Требование с числом сужает выбор: «работает без сети» → толстый клиент
- «200 пользователей одновременно» → монолит выдержит, распределять незачем
- У каждого стиля есть цена, её называем вслух
- Решение записываем вместе с отвергнутыми вариантами
Почему не микросервисы для команды из 2–4 человек
- Независимые команды не нужны: команда одна
- Каждый сервис — свой деплой, свои логи, свои отказы
- Данные одной операции расходятся по базам, транзакции становятся распределёнными
- Модульный монолит даёт границы без сетевых вызовов
Отдельный сервис оправдан, когда у части системы своя нагрузка, своя технология или свой ритм выпусков
Ваш проект: две минуты
- Ответьте на пять вопросов о стиле для своей системы
- К каждому ответу — одно требование, которое его оправдывает
- Где ответа нет или он «потому что модно», там риск для RAT-PoC
C4: как нарисовать архитектуру
Модель C4: четыре уровня
- Контекст: система, её пользователи и внешние системы
- Контейнеры: всё, что запускается отдельно или хранит данные
- Компоненты: крупные части внутри одного контейнера
- Код: классы и функции, рисуем почти никогда
Саймон Браун, c4model.com. Контейнер в C4 — не Docker-контейнер

Архитектура Zulip
Уровень 1: контекст
Уровень 2: контейнеры
Правила нотации
- У элемента: имя, тип, технология и одна строка «что делает»
- Каждая стрелка подписана: что передаёт и по какому протоколу
- Стрелка идёт от того, кто начинает взаимодействие
- Один уровень на одной схеме, в заголовке уровень и область
- Легенда: что значат цвета, формы и линии
Типичные ошибки на защите
- Стрелки без подписей или с подписью «данные»
- Контейнеры и компоненты на одной схеме
- Люди и внешние системы нарисованы внутри границы системы
- Нет пользователей и внешних систем на уровне контекста
- Схема не совпадает с тем, что показано в сборке
Чем рисовать
- Structurizr DSL: модель отдельно, схемы из неё
- PlantUML с библиотекой C4-PlantUML
- Mermaid: поддержка C4 пока экспериментальная
- draw.io с набором фигур C4
Модель напишет DSL по описанию, но путает уровни и придумывает технологии: проверяйте по правилам нотации
ADR: как записать решение
Architecture Decision Record
- Заголовок: решение одной строкой
- Статус: предложено, принято, заменено другим ADR
- Контекст: требования, ограничения и риски, которые вынуждают решать
- Решение: что выбрали и какие варианты отвергли
- Последствия: что получаем и чем платим
Майкл Найгард, 2011. Один файл на решение в docs/adr/ репозитория; принятый ADR не правят, а заменяют новым
Пример: ADR-0001 сайта курса
Контекст и решение
- Сайт поддерживает один человек
- Пользователей около шестидесяти, пик — субботнее занятие
- Решение: один сервис на Astro и SQLite в одном контейнере
- Отвергли: PostgreSQL отдельным сервисом, разделение на сервисы
Последствия
- Деплой — пересобрать один контейнер
- Бэкап базы — копия одного файла
- Запись идёт в одну очередь, горизонтально не масштабируется
- Пересмотреть, если пользователей станет в десять раз больше
К защите RAT-PoC
- C4 уровней 1 и 2, по правилам нотации
- Стиль по каждому важному вопросу и требование, которое его оправдывает
- ADR на два-три ключевых решения
- Самое рискованное допущение часто архитектурное: как его проверили, запишите в последствия
← → листать · F на весь экран · P режим докладчика · Esc выйти
Все слайды
О чём лекция
Требования к системе у нас есть. Сегодня — из чего её собрать, почему именно так и как это показать на защите RAT-PoC.
- Пять вопросов вместо списка стилей. Где выполняется логика, как связаны узлы, что развёртываем, как организован код, как общаются части. Каждый стиль отвечает на один из них, поэтому реальная система — сочетание ответов.
- Клиент и сервер. Клиент-сервер и P2P (BitTorrent, блокчейн). Толстый и тонкий клиент, почему SPA — гибрид.
- Что развёртываем. Монолит, модульный монолит и микросервисы: плюсы, минусы и цена. Закон Конвея и serverless как способ запускать бэкенд.
- Код и взаимодействие. Слоистая архитектура и изоляция слоёв, событийно-ориентированная архитектура (посредник и брокер), микроядро.
- Как выбирать. От нефункциональных требований к стилю и почему команде из двух-четырёх человек почти всегда хватает модульного монолита.
- C4. Четыре уровня, правила нотации и типичные ошибки на защите. Контекст и контейнеры на примере Zulip.
- ADR. Как записать архитектурное решение: контекст, решение, отвергнутые варианты, последствия. Пример — решение, на котором построен сайт курса.
Что сделать сегодня
- Ответить на пять вопросов о стиле для своего проекта и к каждому ответу подобрать требование, которое его оправдывает.
- Нарисовать C4 уровней 1 и 2 для своей системы и проверить их по правилам нотации со слайдов.
- Записать первый ADR: самое важное архитектурное решение проекта вместе с отвергнутыми вариантами.