Всем привет, меня зовут Сергей Прощаев. Я Tech Lead и руководитель направления Java/Kotlin‑разработки в FinTech и E‑commerce, а ещё преподаю на курсах разработки и архитектуры в OTUS.

Представьте: вам как системному аналитику выдали задачу — внедрить новый механизм кэширования в высоконагруженный API‑шлюз. Вокруг 12 микросервисов, три команды разработки, бизнес‑спонсор, который хочет «просто ускорить всё», и Confluence, где документация умерла год назад. С чего начать? Кому какую диаграмму показать? И как не утонуть в бесконечных уточнениях?

Ответ: C4-модель. Это не очередной UML. Это прагматичный инструмент, который позволяет за четыре уровня детализации говорить на одном языке с бизнесом, архитекторами и разработчиками. Методология была предложена Саймоном Брауном и подробно описана на официальном сайте c4model.com. Я сам, пережив несколько проектов с неделями согласований, пришёл к выводу: C4 помогает заметно сократить время согласования архитектурных решений.

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

Запомните простое правило:

• Context — кто использует систему.

• Container — из каких крупных частей система состоит.

• Component — из чего состоит каждый контейнер.

• Code — внутренняя реализация компонента (классы, модули, пакеты и их связи).

Всё остальное — детали. Держите эту лестницу в голове, и C4 перестанет быть абстракцией.

Исходные условия

Допустим, у вас есть:

• Микросервисная архитектура из 10 сервисов (аутентификация, заказы, доставка, API‑шлюз и др.).

• Команда из 12 человек: разработчики, тестировщики, продакт‑менеджер.

• Ближайший релиз через 3 недели.

• Старая документация — мёртвый груз в Confluence.

• Ваша задача — внедрить кэширование в API‑шлюз, чтобы уменьшить нагрузку на бэкенды.

Ограничения: нельзя менять код бэкенд‑сервисов (только шлюз). Времени на согласование — 2 дня.

Почему вообще возникла проблема?

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

Примечание: В канонической C4 четыре уровня. Во многих командах системный аналитик редко работает на уровне исходного кода, поэтому далее мы сосредоточимся на первых трёх уровнях модели и добавим одну динамическую диаграмму (sequence), чтобы показать сценарии ошибок.

Шаг 1. Рисуем контекстную диаграмму (Уровень 1) — для всех стейкхолдеров

Контекстная диаграмма показывает систему как чёрный ящик. Она отвечает на вопрос: кто взаимодействует с нашей платформой и от каких внешних систем она зависит. Внутренние сервисы (Auth, Orders, Delivery) на этом уровне не раскрываются.

Вот корректная контекстная диаграмма для нашего примера (рис. 2):

Система «E‑Commerce Platform» видна снаружи как чёрный ящик. Её внешнее окружение — это пользователь и три смежные системы (платёжная, почтовая, CRM). Главная мысль: на этом уровне не нужно показывать внутренние сервисы — достаточно обозначить, с кем система общается и кто её использует. Это та картинка, которую легко согласовать с бизнесом.

Что делаем: садимся с продакт‑менеджером и за 15 минут набрасываем всех внешних акторов и смежные системы. Не углубляемся внутрь.

Проверка результата: спросите бизнес‑спонсора: «Видит ли он на этой схеме все внешние сервисы, от которых зависит наша платформа?» Если да — шаг выполнен.

Шаг 2. Определяем контейнеры (Уровень 2) — согласуем с архитектором

Контейнер в C4 — это отдельно развёртываемый или запускаемый вычислительный элемент либо хранилище данных. Не путайте с Docker: здесь контейнером может быть веб‑приложение, база данных, очередь сообщений или даже мобильное приложение.

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

Внутри платформы скрываются отдельные исполнимые блоки: API‑шлюз, сервисы аутентификации, заказов, доставки, базы данных PostgreSQL и кэш Redis. Стрелки с подписями (HTTPS, REST, SQL, Cache API) показывают протоколы взаимодействия. Главный вывод: контейнерный уровень — это карта технологических блоков, по которой архитектор и команды видят, какие компоненты есть и как они общаются.

Что делаем: обсуждаем с архитектором и тимлидами:

• Используем JWT или серверные сессии?

• Кэш размещаем в Redis или в памяти приложения?

• Как организовано хранение заказов и доставки?

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

Шаг 3. Детализируем компоненты (Уровень 3) — вместе с командой разработки

Теперь заглянем внутрь API‑шлюза и покажем его ключевые логические компоненты. Схема не изображает строгий линейный конвейер — вместо этого каждый компонент может взаимодействовать с маршрутизатором или друг с другом в зависимости от реализации. Ниже показаны зоны ответственности (рис.4).

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

Что делаем: собираем команду разработки (2–3 человека) и рисуем эту схему за 30 минут. Обсуждаем:

• Какой компонент за что отвечает.

• Стратегия кэширования: Cache‑Aside с TTL. В данном примере показан один из возможных вариантов реализации Cache‑Aside, при котором запись в кэш выполняется асинхронно и не задерживает ответ пользователю.

• Что произойдёт, если кэш упадёт (fallback на бэкенд).

Проверка результата: покажите схему разработчику, который будет писать код. Спросите: «Ты видишь все ключевые компоненты и зоны ответственности, которые предстоит реализовать?» Если нет — детализируйте.

Шаг 4. Добавляем динамику (Sequence Diagram) для сценариев ошибок

C4 — статическая модель. Она не показывает последовательность вызовов во времени. Поэтому для сценариев с кэшем добавляем динамическую диаграмму. Вот как выглядит счастливый путь для запроса GET /orders. Обратите внимание: ответ пользователю отправляется до асинхронной записи в кэш, чтобы не блокировать пользователя.

На рисунке 5 у меня показан классический сценарий Cache‑Aside при обращении к заказам. Сначала шлюз проверяет Redis — получает «miss» (данных нет). Затем шлюз вызывает сервис заказов, получает ответ, сразу возвращает его пользователю и только после этого асинхронно записывает данные в Redis. Это решает главную задачу: пользователь не ждёт записи в кэш, что сохраняет низкую задержку ответа.

Для сценария с таймаутом кэша: если Redis не отвечает, шлюз идёт напрямую в бэкенд, возвращает результат пользователю, а попытка записи в кэш пропускается.

Что делаем: рисуем sequence‑диаграмму для основного потока и фиксируем алгоритм обработки ошибок.

Проверка результата: спросите инженера по нагрузке: «Что будет с задержками, если кэш упал?» Ответ должен совпадать с описанным поведением.

Шаг 5. Закоммитить диаграммы как код (бонус для 2026 года)

Самая большая боль — дрейф архитектуры (диаграммы живут своей жизнью, а код — своей). С ростом скорости разработки и распространением AI‑assisted development документация во многих командах устаревает быстрее.

Что делаем: используем Structurizr DSL — текстовое описание C4-модели. Расширенный пример:

workspace {
    model {
        user = person "Пользователь"
        system = softwareSystem "E-Commerce Platform" {
            apiGateway = container "API Gateway"
            auth = container "Auth Service"
            orders = container "Orders Service"
            redis = container "Redis"
        }

        user -> apiGateway "Uses"
        apiGateway -> auth "Authenticates (JWT)"
        apiGateway -> orders "Requests orders (REST)"
        apiGateway -> redis "Reads/Writes cache (Cache API)"
    }
    views {
        systemContext system {
            include *
        }
        container system {
            include *
        }
    }
}

Файл кладётся в Git. CI/CD может автоматически пересобирать диаграммы. Для проверки архитектуры добавляют архитектурные тесты.

Проверка результата: зайдите в репозиторий — есть ли .dsl или .puml? Если да, вы используете Architecture as Code.

Где C4 не сработает? (Ограничения)

Я бы предпочёл быть честным с моими читателями. C4 — мощный, но не панацея.

Представьте, что вам нужно описать процесс согласования заявок или маршрут обработки инцидента. C4 здесь бессилен: он статичен, а вам нужны ветвления, состояния, потоки событий. Для таких задач берите BPMN — это совсем другой инструмент.

Или другой пример: вы хотите показать тайминги вызовов между микросервисами, параллельные запросы или сценарий deadlock'а. C4 снова не помощник. Статической картинки недостаточно — тут пригодятся sequence или activity‑диаграммы. Именно поэтому мы и добавили одну такую диаграмму в статью.

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

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

Что дальше? От слов к делу

Мы разобрали по шагам, как системному аналитику внедрить C4-модель и sequence‑диаграммы: от контекста до «архитектуры как код». Такой подход позволяет участвовать в архитектурных обсуждениях и говорить с разработчиками, архитекторами и бизнесом на одном языке.

Если вам понравился этот практический разбор, приглашаю вас на открытые уроки в рамках курса «Системный аналитик: Управление командой» в OTUS. Это хорошая возможность познакомиться с преподавателями, оценить формат обучения и задать вопросы по своим рабочим задачам.

• 17 июня, 20:00. «Архитектура информационных систем. Монолиты, SOA и микросервисы». Записаться

• 24 июня, 20:00. «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах». Записаться

• 25 июня, 20:00. «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». Записаться

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