Модель C4

Модель C4 была создана архитектором программного обеспечения Саймоном Брауном в период с 2006 по 2011 год на основе идей унифицированного языка моделирования (UML) и модели архитектурных представлений 4+1. Появление официального сайта под лицензией Creative Commons^[4] и публикация статьи в 2018 году способствовали росту популярности этой техники. В 2024 году на конференции GOTO Саймон Браун представил доклад, посвящённый разбору частых ошибок и рекомендациям по применению модели для современных архитектур, включая микросервисы, микрофронтенды и событийно-ориентированные системы^[5].

Модель C4 описывает архитектуру программной системы, показывая различные уровни представления, которые объясняют декомпозицию системы на контейнеры и компоненты, их взаимосвязи, а при необходимости — связи с пользователями^[4].

Диаграммы организованы по иерархическим уровням:^[4]

• Контекстные диаграммы (уровень 1): показывают систему как «чёрный ящик» и демонстрируют её взаимодействие с пользователями (акторами) и другими внешними системами^[3];
• Диаграммы контейнеров (уровень 2): декомпозируют систему на отдельно развёртываемые единицы (контейнеры), такие как веб-приложения, базы данных или микросервисы^[3];
• Диаграммы компонентов (уровень 3): детализируют внутреннее устройство отдельного контейнера, представляя компоненты как логические группы связанного функционала^[3];
• Диаграммы кода (уровень 4): показывают реализацию отдельного компонента на уровне исходного кода с использованием таких нотаций, как унифицированный язык моделирования (UML) или диаграммы «сущность-связь» (ERD)^[3].

Помимо основных уровней, модель C4 включает дополнительные диаграммы: динамическую (для отображения взаимодействия во время выполнения) и диаграмму развёртывания (для сопоставления контейнеров с инфраструктурой)^[6].

Модель также адаптируется для облачных (cloud-native) и бессерверных (serverless) архитектур. В таких системах в качестве контейнеров могут выступать серверные функции (например, AWS Lambda) и управляемые сервисы, а компонентами считаются внутренние модули этих функций^[7].

Для уровней 1-3 модель C4 использует 5 основных элементов диаграммирования: люди, программные системы, контейнеры, компоненты и взаимосвязи. Техника не регламентирует дизайн, форму, цвет или стиль этих элементов; вместо этого рекомендуется использовать простые схемы на основе вложенных блоков для облегчения коллективной и интерактивной работы. Модель C4 также поощряет хорошие практики моделирования, такие как указание заголовка и легенды на каждой диаграмме, а также чёткое и однозначное маркирование для лучшего понимания целевой аудиторией.

Модель C4 способствует совместной визуализации архитектуры и поддерживает эволюционную архитектуру в командах, работающих по гибким методологиям, где не требуется формальное документирование и сложное предварительное проектирование^[8].

Для создания и поддержки диаграмм C4 применяются подходы «Архитектура как код» (Architecture as Code) и «Диаграммы как код» (Diagrams as Code). Они предполагают описание архитектуры в виде текста на специализированном языке, что позволяет автоматизировать генерацию графических представлений. Де-факто стандартами нотации стали язык Structurizr DSL, реализующий подход «сначала модель» (model-first) от создателя C4, и библиотека C4-PlantUML^[9].

Экосистема C4 поддерживается различными инструментами. Для работы с кодом архитектуры существуют плагины для интегрированных сред разработки, таких как Visual Studio Code и продукты JetBrains. Визуальное создание диаграмм доступно в графических редакторах и на онлайн-платформах, включая Diagrams.net, Lucidchart и Miro^[10].

Развиваются инструменты автоматической генерации диаграмм напрямую из исходного кода, такие как CodeSee и Uxxu codeToC4^[11]. Кроме того, для создания архитектурных моделей применяется искусственный интеллект: инструменты Cloudairy и C4-PlantUML Studio позволяют генерировать диаграммы на основе текстовых описаний^[12].

В 2024 году инструмент IcePanel, использующий модель C4 для совместного моделирования, был включён в технологический радар компании Thoughtworks в категорию «Assess» (Оценка)^[13].

Согласно принципу 80/20, уровни контекста и контейнеров обеспечивают около 80 % ценности модели для большинства аудиторий, поэтому именно на них рекомендуется делать основной упор при постоянной поддержке архитектурной документации^[7]. Нижние уровни модели (компоненты и код) подвергаются критике из-за высокой трудоёмкости их создания и быстрого устаревания при ручном обновлении^[14][15]. Уровень кода считается опциональным, и его ручная поддержка признаётся нецелесообразной. Для визуализации этого уровня рекомендуется использовать исключительно автоматическую генерацию диаграмм напрямую из исходного кода^[16].