Архитектурные представления C4

В проекте часто есть требования, сценарии, диаграммы классов, компоненты и схема развёртывания, но новому участнику всё равно трудно ответить на простой вопрос: как устроена система в целом? Одна большая диаграмма не решает проблему: она смешивает пользователей, классы, базы данных, серверы и детали протоколов.

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

Что такое C4

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

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

Здесь контейнер означает приложение или хранилище данных, необходимое для работы системы. Это не обязательно контейнер в среде Docker. Компонент — группа связанной функциональности за понятным интерфейсом; он не обязан совпадать с UML-компонентом, пакетом или каталогом исходного кода.

Основные и дополнительные представления

Для большинства небольших ИС достаточно двух диаграмм: контекста системы и контейнеров. Они рекомендованы авторами C4 как базовый набор. Остальные представления строят, только если они помогают принять решение, обнаружить проблему или объяснить существенную часть системы.

Представление	Когда добавлять	Что не показывать вместо него
Ландшафт систем	нужно показать портфель систем организации	одну выделенную проектируемую систему
Компоненты	контейнер стал слишком сложным для обсуждения одним блоком	каждый класс и внутренний вызов
Код	важный компонент нельзя объяснить существующей технической моделью	весь исходный код
Динамика	сложный сценарий требует показать архитектурное взаимодействие	все сценарии подряд
Развёртывание	важны конкретное окружение и размещение экземпляров	логическое разбиение на контейнеры

C4 в маршруте курса

C4 начинается не с рисования. Его элементы выводятся из уже построенных материалов:

граница и стейкхолдеры
→ требования и сценарии
→ предметная и техническая модели
→ проектные решения и архитектура
→ представления C4

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

Сквозной пример

Дальше используется сервис записи на консультации. Одна и та же система последовательно раскрывается так:

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

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

Правила чтения и оформления

Диаграмма должна быть понятна без устного рассказа. Минимальные правила из рекомендаций C4 по нотации:

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

Проверить готовую диаграмму помогает официальный контрольный список C4.

Что дальше

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