Модели описания архитектуры — C4 и 4+1

Общее #

C4 Model («модель C4») и 4+1 View Model («модель представлений 4+1», «четыре плюс один») — два канонических подхода к документированию и визуализации архитектуры программного обеспечения, отвечающие на практический вопрос, который рано или поздно встаёт перед каждой командой: как описывать и как рисовать архитектуру. 4+1, предложенная Филиппом Крухтеном (Philippe Kruchten) в статье Architectural Blueprints — The «4+1» View Model of Architecture (IEEE Software, 1995), разделяет описание системы на пять взаимодополняющих представлений, каждое из которых адресовано своей аудитории — от конечных пользователей до инженеров развёртывания.

C4, созданная консультантом Саймоном Брауном (Simon Brown; идея оформилась у него ещё в середине 2000-х, публично модель продвигалась в 2010-е через доклады, книгу Software Architecture for Developers и инструмент Structurizr, каноническое описание — сайт c4model.com), предлагает четыре уровня детализации — Context, Container, Component, Code — по принципу зума карт: наблюдатель сам выбирает масштаб, начиная с системы во внешнем окружении и приближаясь при необходимости вплоть до отдельных классов.

Оба подхода отвечают на одну и ту же боль — проблему «одной картинки». Наивное представление об архитектурной документации звучит так: «нарисуем диаграмму системы». Практика показывает, что одной диаграммы не существует: разным аудиториям нужны принципиально разные уровни детализации. Инвестору или генеральному директору достаточно понять, с кем интегрируется продукт и где проходит его граница — это диаграмма из пяти-семи коробок. Новому разработчику нужно понять, из каких приложений, баз и очередей состоит система и по каким протоколам они общаются. Архитектору, меняющему один модуль, нужны внутренности конкретного контейнера. Попытка усидеть на всех стульях одновременно порождает знакомую каждому картину: лист A0, на котором в одной плоскости смешаны акторы, микросервисы, таблицы баз данных, кластеры Kubernetes и стрелки без подписей — диаграмма, нечитаемая ни для одной из аудиторий. «Одна диаграмма для всех» не работает не потому, что её трудно нарисовать, а потому, что вопрос «что такое эта система» имеет разные правильные ответы в зависимости от того, кто спрашивает.

Исторически подходы разделены почти двадцатью годами и двумя эпохами индустрии. 4+1 родилась внутри Rational Software — Крухтен руководил там разработкой процесса RUP (Rational Unified Process), и модель представлений стала архитектурным ядром этого тяжёлого итеративного процесса: RUP предписывал вести и поддерживать все четыре представления плюс сценарии. C4 — продукт следующей эпохи: к 2010-м UML, стандартизованный консорциумом OMG в 1997 году на работах «трёх амиго» (Буч, Рамбо, Якобсон), в повседневной практике массово «обесценился» — из инженерного языка он превратился в набор значков, которые рисуют ради самих диаграмм, а не для коммуникации. Браун сформулировал ответ: проблема не в том, что UML плох, а в том, что большинство людей нужно не четырнадцать типов строгих диаграмм, а несколько простых уровней абстракции с честными подписями. C4 и стала таким ответом — «абстракции важнее нотации».

Модели описания архитектуры уже мелькали в этой базе знаний по касательной: в статье об ADR упоминается Крухтен — автор 4+1 и практик фиксации архитектурных решений, а в TOGAF описана концепция представлений и точек зрения (views/viewpoints), родственная по духу. Эта статья раскрывает обе модели целиком: механику 4+1, четыре уровня C4, их соотношение между собой и с UML, а также связь с уровнями проектирования HLD/LLD и записями решений.

Ключевая мысль, которую стоит зафиксировать до подробностей: C4 и 4+1 не конкурируют. Они отвечают на разные вопросы. 4+1 говорит, какие взгляды на систему нужны и для кого; C4 — как эти взгляды рисовать и на каком уровне зума. Зрелая архитектурная документация спокойно использует обе рамки: представления из 4+1 как чек-лист полноты, уровни C4 как способ построения каждой картинки.

Стоит сразу определить и место обеих моделей в таксономии этой базы знаний. C4 и 4+1 — модели описания (description models): они говорят о том, как документировать и визуализировать архитектуру, — в отличие от архитектурных стилей вроде слоистой, гексагональной или Clean Architecture, которые определяют, как архитектуру устраивать, и от введения в архитектуру, где разбираются базовые понятия дисциплины. Модель описания применима к системе, построенной в любом стиле: контейнерную диаграмму можно нарисовать и для монолита, и для микросервисной декомпозиции — стиль меняет содержимое коробок, не модель их изображения.

4+1 View Model: пять представлений #

Механика модели #

Крухтен исходил из наблюдения, сделанного на материале аэрокосмических и телекоммуникационных систем: описание архитектуры сложной системы не помещается в одно представление, а «универсальная» диаграмма неизбежно либо перегружена, либо пуста. Решение — описывать архитектуру набором представлений (views), каждое из которых отвечает на свою группу вопросов и адресовано своей аудитории. Сама архитектура при этом не сводится ни к одному из представлений: полна только их совокупность — представления взаимодополняемы, а ни одно по отдельности не является достаточным. Это и есть центральный тезис модели, отличающий её от «нарисуй систему».

Модель названа «4+1», потому что состоит из четырёх представлений плюс одного связующего:

• Logical View (логическое представление) — функциональность системы: из каких функциональных элементов она состоит и какие возможности предоставляет конечному пользователю. Здесь живут доменные сущности и декомпозиция на элементы, предоставляющие сервисы пользователю.
• Process View (процессное представление) — система в рантайме: параллелизм, распределение процессов, интеграция, взаимодействие, производительность, масштабирование, доступность. Ответ на вопрос «как система ведёт себя во время выполнения».
• Development View (представление разработки) — организация программного обеспечения: модули, слои, библиотеки, переиспользование, сборка. Это взгляд программиста на кодовую базу.
• Physical View (физическое представление) — отображение программных артефактов на железо: ноды, процессоры, сети, развёртывание. Сегодня его естественная аудитория — DevOps и инфраструктурные инженеры.
• Scenarios (сценарии, «+1») — небольшое число важнейших сценариев использования, которые связывают четыре остальных представления и проверяют их целостность.

Сводная таблица модели:

        ┌────────────────────────┐        ┌────────────────────────┐
        │        Logical         │        │        Process         │
        │   функциональность,    │        │  параллелизм, интег-   │
        │ конечные пользователи  │        │     рация, рантайм     │
        └────────────┬───────────┘        └─────────────┬──────────┘
                     │                                  │
                     │         ┌─────────────┐          │
                     └────────▶│  Scenarios  │◀─────────┘
                     ┌─────────│    (+1)     │──────────┐
                     │         └─────────────┘          │
                     │                                  │
        ┌────────────┬───────────┐        ┌─────────────┬──────────┐
        │      Development       │        │        Physical        │
        │  модули, библиотеки,   │        │     ноды, железо,      │
        │    организация кода    │        │     развёртывание      │
        └────────────────────────┘        └────────────────────────┘

Представления в деталях #

Logical View описывает систему глазами её пользователей: набор функциональных возможностей, выраженный через декомпозицию на элементы предметной области. В объектной традиции, в которой работал Крухтен, это классы и пакеты доменных сущностей; в UML-эпоху логическое представление рисовали диаграммами классов и объектов. Для сегодняшнего читателя полезнее думать о нём как о «функциональном разрезе»: какие части системы за что отвечают с точки зрения предметной области — ответ на вопрос «что система делает», без вопросов «как это выполняется и где лежит». Ближайшие соседи по духу в современной практике — доменные модели DDD и концептуальные модели данных.

Process View — самый инженерный из четырёх: он показывает систему во время выполнения. Сколько процессов и потоков, как они взаимодействуют и синхронизируются, как распределяется нагрузка, где границы отказоустойчивости, как система интегрируется с внешними системами в рантайме. Крухтен адресовал его «интеграторам» — роли, отвечающей за сборку целого из частей и за нефункциональные характеристики: производительность, доступность, масштабируемость. Именно здесь живут ответы на вопросы о конкурентном доступе, репликации и деградации при отказе узла. В современной терминологии это близко к runtime-представлению о системе: кто кого вызывает, синхронно или через очередь, что происходит при пиках нагрузки.

Development View — взгляд программиста: как кодовая база организована в модули, слои и библиотеки, что от чего зависит, что переиспользуется между продуктами. Крухтен писал его для аудитории «программисты, ведущие разработку» и менеджеров, отвечающих за сборку: на этом представлении видны компоненты, которые можно раздавать командам, и границы для переиспользования. Показательно, что в RUP его переименовали в Implementation View — представление реализации. Именно это представление ближе всего к тому, что сегодня рисуют на уровне контейнеров и компонентов C4, а его внутренняя организация — тема стилевых статей: слоистой, гексагональной, Clean Architecture.

Physical View отображает программные артефакты на инфраструктуру: на каких машинах и узлах что исполняется, как узлы соединены сетью, где резервирование. Аудитория — «развёртыватели»: в 1995 году это системные инженеры, сегодня — DevOps и SRE. Форма этого представления дожила до наших дней почти без изменений: диаграммы развёртывания с нодами, кластерами, зонами доступности и managed-сервисами — прямой потомок Physical View. Существенно, что разным целям соответствуют разные физические конфигурации: тестовый стенд, установка у одного клиента, отказоустойчивый прод — Крухтен прямо оговаривает, что физических представлений может быть несколько.

Соответствие диаграммам UML #

Статья Крухтена писалась в момент, когда объектные нотации (методы Буча, OMT Рамбо, OOSE Якобсона) сливались в единый UML, и для каждого представления модель указывала естественный ему тип диаграмм. Соответствие стало классическим — его до сих пор приводят в учебниках по архитектуре:

Из таблицы видно важное свойство модели: 4+1 предписывает представления, но не придумывает для них новой графики — каждое представление рисовалось существующими средствами той нотации, которая вскоре стала UML. Именно эта опора на строгий UML впоследствии стала мишенью для критики: диаграммы классов и состояний требуют подготовки и от рисующего, и от читающего, а на практике чаще всего нужна была одна-две простые картинки «кто с кем говорит» — ниша, которую позже заняла C4.

Scenarios: «+1» как проверка целостности #

Пятое представление — Scenarios, сценарии использования — играет особую роль и потому вынесено в название модели как «+1». Крухтен использует небольшое число наиболее значимых сценариев (в его примере для системы управления воздушным движением — несколько десятков из сотен) двумя способами. Во-первых, как клей: сценарий проходит по всем четырём представлениям — затрагивает функциональные элементы в Logical, исполнение в Process, модули в Development и узлы в Physical, — связывая разрозненные описания в одну систему. Во-вторых, как проверку полноты и состоятельности: если хотя бы одно представление не может пропустить критичный сценарий, архитектура где-то несостоятельна — не описан нужный элемент, не проложен путь данных, не учтено взаимодействие. Сценарии — самый дешёвый способ найти дыру в описании до того, как её найдёт продакшен.

Роль сценариев стоит подчеркнуть отдельно, потому что её часто упускают, сводя 4+1 к «пяти диаграммам». В оригинале сценарии — не ещё одна диаграмма рядом с четырьмя, а механизм верификации архитектуры: аналитик берёт критичный пользовательский сценарий и «прогоняет» его по представлениям, проверяя, что каждое отвечает на свою часть пути. Позже эта идея в разных формах всплывёт в индустрии: сквозные сценарии в HLD, архитектурно-значимые варианты использования в книгах по программной архитектуре, «холодные» walkthrough-сессии на дизайн-ревью.

Наследие и влияние #

Судьба 4+1 тесно связана с судьбой RUP. Внутри процесса модель закрепилась под слегка изменёнными именами: представления стали называться Use-Case View (сценарии), Logical View, Implementation View (разработка), Process View и Deployment View (физическое), а каноническим артефактом стал документ SAD (Software Architecture Document), собирающий все представления под одной обложкой. RUP предписывал вести SAD с ранних итераций и поддерживать на протяжении жизни системы — отсюда и репутация модели как «тяжёлой»: в её оригинальном доме представления были не советом, а обязательным артефактом процесса.

Влияние модели шире её прямого применения: идея «нескольких представлений под разные concerns» была стандартизована в IEEE 1471 (2000; позже ISO/IEC/IEEE 42010) — стандарте описания архитектуры, где центральное место занимают представления и точки зрения, — и вошла в TOGAF как глава о views/viewpoints. Когда Саймон Браун формулирует «разным людям нужны разные диаграммы», он — возможно, не называя источника — воспроизводит центральный тезис Крухтена.

C4 Model: четыре уровня зума #

Механика: метафора карт #

C4 отвечает на вопрос «как рисовать» через метафору карт и зума, которую Браун повторяет как рефрен: работая с картой города, вы сначала видите страну, затем область, затем город, улицу и дом — и на каждом масштабе видите разное, при этом карта остаётся одной. Так же и архитектура: система — это одна территория, но показывать её нужно на разных уровнях детализации в зависимости от того, кто смотрит. C4 фиксирует четыре таких уровня — Context, Container, Component, Code — и для каждого задаёт аудиторию и содержание. Ни один уровень не «главнее»: ценность именно в возможности переходить между ними, не теряясь.

Сквозной пример, на котором ниже показаны первые два уровня, — интернет-магазин: покупатель работает с веб-приложением, веб-приложение обращается к API-сервису, тот хранит данные в базе заказов и обращается к внешнему платёжному шлюзу.

Уровень 1: System Context #

Контекстная диаграмма показывает систему как одну коробку в центре — чёрный ящик без внутренностей — и всё, что её окружает: людей (пользователей, администраторов, операторов поддержки) и внешние системы, с которыми система обменивается данными. Никаких баз данных, очередей и микросервисов внутри на этом уровне нет: контекст отвечает строго на вопросы «что это за система, кто ею пользуется и с чем она интегрируется». Это диаграмма для всех: её должен понять и генеральный директор, и новый разработчик, и менеджер партнёрского отдела. Практическая роль огромна — контекст фиксирует границу системы и объём ответственности команды, и именно на нём проще всего поймать недопонимание «а платёжный шлюз — это мы или не мы?».

┌────────────────┐                 ┌──────────────────────┐                 ┌──────────────────────┐
│   Покупатель   │                 │                      │   принимает     │   Платёжный шлюз     │
│    (человек)   │──── покупает ──▶│   Интернет-магазин   │──── платежи ───▶│  [внешняя система]   │
└────────────────┘                 │      [наша система]  │                 └──────────────────────┘
                                   │                      │
┌────────────────┐                 │                      │                 ┌──────────────────────┐
│   Маркетолог   │──── товары ────▶│                      │◀─── остатки ────│  Складская система   │
│    (человек)   │                 └──────────────────────┘                 │  [внешняя система]   │
└────────────────┘                                                          └──────────────────────┘

Стрелки на диаграмме подписаны не типом линии, а смыслом: «покупает товары», «принимает платежи», «запрашивает остатки». Читателю не нужна легенда — диаграмма объясняет себя сама.

Уровень 2: Containers #

Контейнерная диаграмма — первый «зум внутрь» системы. Контейнер в терминологии C4 — это самостоятельно исполняемая единица внутри системы: серверное приложение, одностраничное веб-приложение в браузере, мобильное приложение, настольный клиент, база данных, брокер сообщений, файловая система. Контейнеры обмениваются данными по протоколам, которые на этом уровне уже обязаны быть названы: REST/JSON, gRPC, SQL, AMQP. Уровень адресован технической аудитории — именно эту картинку имеет в виду разработчик, спрашивающий «как у нас всё устроено»; именно она служит границей между HLD и LLD.

┌────────────────┐              ┌──────────────────────────┐
│   Покупатель   │─── HTTPS ───▶│     Веб-приложение       │
│    (человек)   │              │  [SPA, TypeScript]       │
└────────────────┘              └────────────┬─────────────┘
                                             │ REST/JSON
                                             ▼
                                 ┌──────────────────────────┐   REST/JSON   ┌──────────────────────┐
                                 │       API-сервис         │──────────────▶│  Платёжный шлюз      │
                                 │   [JVM, Spring Boot]     │               │  [внешняя система]   │
                                 └───────────┬──────────────┘               └──────────────────────┘
                                             │ SQL, чтение/запись
                                             ▼
                                 ┌──────────────────────────┐
                                 │       БД заказов         │
                                 │      [PostgreSQL]        │
                                 └──────────────────────────┘

Здесь неизбежно встаёт терминологическая оговорка, которую Браун делает сам в каждом докладе: Container ≠ Docker-контейнер. Термин появился в C4 раньше, чем Docker стал массовым (модель оформилась в середине 2000-х, Docker вышел в 2013-м), и означает «исполнимый блок системы», а не единицу виртуализации. Один Docker-контейнер может хостить один C4-контейнер, а может — несколько; база данных как C4-контейнер при этом запускается в контейнере Docker — слова совпадают, смыслы разные. В командах, где слово «контейнер» перегружено, Браун советует проговаривать термин явно или заменять его на нейтральное «исполнимые единицы».

Уровни 3 и 4: Components и Code #

Третий уровень зумит внутрь одного контейнера — как правило, самого богатого логикой, например API-сервис магазина. Компонент — модуль контейнера: группа классов или сервисов с общей ответственностью и явным интерфейсом. На компонентной диаграмме API-сервиса магазина появятся OrderComponent (оформление заказов), CatalogComponent (каталог), PaymentComponent (обёртка над платёжным шлюзом), NotificationComponent (уведомления) и их зависимости. Аудитория — разработчики этого контейнера и архитектор; именно на этом уровне становятся видимыми внутренние слои и границы, о которых говорят статьи об архитектурных стилях: домен, отделённый от инфраструктуры в духе Clean Architecture, на компонентной диаграмме выглядит как отдельная группа компонентов без зависимостей на технические группы.

По подписям компонентная диаграмма чуть строже остальных уровней: каждому компоненту рекомендуется указать не только имя, но и однофразную ответственность («оформляет заказ, применяет скидки, публикует событие OrderPlaced») и интерфейс, через который к нему обращаются соседи. Такая дисциплина превращает диаграмму в рабочий инструмент: когда ответственность сформулирована, дублирование и «мусорные» компоненты без ясной роли становятся видны сразу — задолго до того, как превратятся в проблему в коде.

Четвёртый уровень — Code: классы и интерфейсы внутри компонента, то есть классическая диаграмма классов. Браун честно называет его наименее полезным: код — лучший источник правды о самом себе, и диаграмма классов почти всегда либо устарела, либо не нужна; инструмент разработки умеет показать структуру точнее и свежее. Уровень существует в модели для полноты зума, а на практике рисуется по требованию — например, для внешнего по отношению к команде контракта — и лучше всего генерируется из кода, а не вручную.

Дополнительные диаграммы #

Помимо четырёх статических уровней, C4 включает несколько вспомогательных диаграмм. Dynamic Diagram показывает поведение во времени: порядок и варианты взаимодействия контейнеров и компонентов в конкретном сценарии — «что происходит от клика „Оплатить“ до письма с подтверждением». Deployment Diagram показывает, на каких узлах и в каких средах исполняются контейнеры: тестинг, стейджинг, прод, зоны доступности. Наконец, System Landscape — расширенный контекст: не одна система в окружении, а ландшафт связанных систем организации целиком; полезен там, где продуктов несколько и интеграции между ними запутаны. Заметно, что dynamic и deployment закрывают ровно те вопросы, которые в 4+1 вынесены в Process View и Physical View, — ещё одно подтверждение дополнительности двух моделей, а не их конкуренции.

Нотация: боксы и стрелки #

Отдельная заслуга C4 — позиция по нотации. Модель не предписывает ни одной обязательной графической формы: её тезис — абстракции важнее нотации, подписи важнее значков. Рекомендация практична: каждая коробка подписывается именем, типом (человек, программная система, контейнер, компонент) и одной фразой описания; каждая стрелка — смыслом взаимодействия и протоколом. Не нужно легенды, не нужно изучать стандарт: диаграмма должна читаться человеком, который стандарт не читал. Это сознательная антитеза UML с его четырнадцатью типами диаграмм и строгой семантикой каждой линии; из UML-наследия C4 оставляет только идею уровней абстракции. Если команде комфортно строгая нотация — C4 это допускает: модель определяет, что рисовать, а как — вопрос вкуса и инструмента.

C4 vs 4+1 vs UML #

Три подхода часто ставят в один ряд, но категориально они различны: 4+1 и C4 — модели описания (какие представления/уровни нужны), UML — нотация (какими значками рисовать). UML стандартизован OMG в 1997 году на основе методов Буча, Рамбо и Якобсона и определяет строгий язык диаграмм — от классов и последовательностей до состояний и развёртывания. Модели описания могли бы существовать без UML и наоборот; на практике 4+1 родилась в мире, где UML-диаграммы были естественной формой выражения, а C4 — как протест против их избыточности. Сравнительная таблица:

Соответствие уровней C4 и представлений 4+1 — не взаимно-однозначное, но регулярное, и его полезно держать перед глазами при построении документации:

Читается соответствие так: там, где 4+1 говорит «нужно Process представление», команда на языке C4 рисует dynamic-диаграмму ключевого сценария; там, где 4+1 требует Development View, C4 предлагает два уровня зума — контейнеры и компоненты. Обратное тоже работает: контекстная диаграмма C4, по сути, отвечает на вопрос «кто пользователи системы», то есть начинает логическое представление 4+1 с его внешней границы.

Практические следствия из таблицы сравнения. Первое: подходы не взаимоисключающие — команда может взять у 4+1 чек-лист представлений (не забыть про рантайм и развёртывание), у C4 — уровни зума и лёгкую нотацию, а UML-диаграмму конкретного типа использовать там, где она уместна, например диаграмму последовательностей внутри сценария. Второе: контейнерный и компонентный уровни C4 естественно рассматривать как практическую реализацию Development View из 4+1 — то, что Крухтен адресовал программистам, C4 делает рисуемым на двух уровнях детализации; deployment- и dynamic-диаграммы C4 закрывают Physical и Process View. Третье: выбор рамки — вопрос прагматики. Если команде нужен полный архитектурный документ с формальным покрытием всех ролей (например, в enterprise-контуре с процессной дисциплиной) — 4+1 даёт структуру; если нужна живая коммуникация «как устроено» для wiki и онбординга — C4 быстрее приживается; если в команде сильна культура моделирования и нужны точные исполняемые модели — уместен UML. Чаще всего зрелая документация — комбинация: C4 как несущая рамка, сценарии 4+1 как проверка, UML-диаграммы точечно.

Связь с HLD/LLD и ADR #

Модели описания не живут в вакууме — они встраиваются в процесс проектирования, описанный в статьях об уровнях проектирования. Соответствие уровней C4 классическому делению на High-Level Design и Low-Level Design практически прямое, что отмечается и в самой статье об HLD:

Читается таблица так: HLD ≈ Context + Container — высокоуровневое проектирование отвечает на вопрос «из каких частей состоит система и как они связаны», и контейнерная диаграмма — готовая форма такого описания; физическое представление 4+1 и deployment-диаграмма C4 добавляют к HLD инфраструктурный разрез. LLD ≈ Component + Code — детальное проектирование раскрывает устройство одной части, и это ровно уровни C4 ниже контейнера. Сквозные сценарии, которые HLD-практика использует для проверки, — прямой наследник Scenarios из 4+1. Отдельно стоит упомянуть шаблон arc42 — двенадцатисекционный каркас архитектурного документа, который сам по себе не определяет графику и потому стандартно наполняется именно C4-диаграммами; связка «arc42 как структура документа + C4 как визуальный язык» — распространённый промышленный вариант.

Вторая связка — с ADR, и она носит дополнительный характер. C4-диаграммы отвечают на вопрос «что есть»: как система устроена сейчас. ADR отвечают на вопрос «почему так»: какие рассматривались альтернативы и почему выбрано именно это решение. Вместе они закрывают полный цикл понимания: новый архитектор открывает контейнерную диаграмму, видит выделенный сервис уведомлений, кликает на ссылку и читает ADR, объясняющий, почему уведомления вынесены из основного API (например, соображения независимого масштабирования и отказоустойчивости). Инструменты diagram-as-code это поддерживают напрямую: в Structurizr и C4-PlantUML элемент диаграммы может нести ссылку на документ с решением. Обратная связь тоже работает: ADR на момент принятия решения часто содержит диаграмму целевого состояния — и это снова C4-уровни. В терминологии процессов: диаграммы — это снимок состояния, ADR — журнал решений, приведших к этому состоянию; эволюционная архитектура добавляет к ним третий элемент — механизм управляемых изменений.

Наконец, модели описания задают форму и для разговоров в рамках System Design — собеседования и проектировочные сессии почти всегда движутся по уровням C4: от контекста и требований через контейнеры к компонентам, — а выбор структуры внутри контейнера опирается на стилевые статьи: монолит или микросервисы определяют, сколько контейнеров будет на уровне 2 и где пройдут их границы.

Плюсы #

C4: простота входа #

Порог входа в C4 — минимальный из всех известных подходов к визуализации архитектуры: четыре уровня, три типа коробок, стрелки со смысловыми подписями. Диаграмму первого уровня способен нарисовать и понять человек без инженерной подготовки через пять минут после знакомства с моделью; команда, как правило, начинает получать пользу с первой же контекстной диаграммы, не проходя обучения нотации. Именно низкий порог объясняет массовое распространение модели: контекстная диаграмма стала де-факто стандартом первой страницы технической документации проекта.

C4: иерархический зум #

Метафора карт даёт практический механизм навигации: каждый слушатель разговора об архитектуре сам выбирает уровень — от «что это за система» до «как устроен этот модуль». Зум устраняет и перегрузку (нет попытки показать всё сразу), и путаницу (уровни явно поименованы: «это вопрос уровня контейнеров, а не компонентов»). Иерархия уровней делает диаграммы пригодными для онбординга: новый разработчик проходит Context → Container своей команды за первый день и спускается глубже по мере необходимости.

C4: не требует UML #

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

C4: инструменты и diagram-as-code #

Вокруг модели сложилась зрелая инструментальная экосистема: Structurizr — родительский инструмент Брауна с DSL «модель отдельно, представления отдельно», C4-PlantUML и Mermaid — поддержка C4 в текстовых генераторах диаграмм, diagrams.net (draw.io), LikeC4, IcePanel — графические редакторы с C4-наборами. Text-форма диаграмм (diagram-as-code) даёт три выигрыша сразу: диаграмма живёт в репозитории рядом с кодом, проходит ревью в pull request’ах и датируется тем же commit’ом, что и изменение архитектуры. Это напрямую решает главную болезнь документирования — устаревание.

4+1: полнота охвата #

Главное достоинство 4+1 — систематичность: пять представлений образуют чек-лист, по которому можно проверить, что архитектура описана со всех значимых сторон — функциональность, рантайм, код, развёртывание и сквозные сценарии. Модель не даёт забыть о нефункциональных разрезах: Process и Physical представления заставляют ответить на вопросы параллелизма, производительности и развёртывания, которые в «одной картинке» неизбежно выпадают. Для Enterprise-контура с процессной дисциплиной такая полнота — не избыточность, а требование.

4+1: стейкхолдер-ориентированность #

Модель явно связывает каждое представление с аудиторией и её вопросами: пользователи, программисты, интеграторы, развёртыватели — у каждого своё окно в архитектуру. Это превращает архитектурный документ из «картинки для архитектора» в набор адресных артефактов и снимает споры о том, «как правильно» нарисовать систему: правильно — так, чтобы целевая аудитория представления на свои вопросы ответила. Идея пережила саму модель и вошла в стандарты (IEEE 1471, ISO/IEC/IEEE 42010) и в TOGAF.

Минусы #

C4: уровень Code почти бесполезен #

Четвёртый уровень модели — её самое слабое место, что признаёт и автор. Диаграммы классов по актуальному коду точнее и дешевле строить средствами IDE; вручную нарисованный уровень Code устаревает за один рефакторинг. На практике команды, декларирующие C4, почти всегда останавливаются на трёх уровнях — и модель это допускает, но несимметричность «четырёх уровней, из которых нужен три» регулярно вызывает вопросы у новичков.

C4: критика за упрощение #

Консервативная часть сообщества критикует C4 за потерю строгости: «боксы и стрелки» не несут формальной семантики, и две команды могут нарисовать один и тот же уровень настолько по-разному, что сравнение диаграмм теряет смысл. Сторонники отвечают, что строгость UML на практике тоже не соблюдалась, а цель архитектурной диаграммы — коммуникация, не формальная верификация. Спор в целом воспроизводит давний конфликт «документация как коммуникация» против «документация как спецификация»: C4 честно выбирает первое.

C4: терминологическая путаница «контейнеров» #

Термин Container — самый устойчивый источник недопонимания: в эпоху Docker и Kubernetes слово безусловно читается как «Docker-контейнер». Команды вынуждены каждый раз проговаривать оговорку; в организациях с инфраструктурной культурой это приводит к локальным переименованиям («сервисы», «исполнимые единицы»), что размывает общий словарь модели — ту самую выгоду, ради которой она применялась.

4+1: тяжеловесность родом из RUP #

Модель наследует контекст RUP — процессно-тяжёлую методологию с обязательными артефактами. В современном agile-контуре «поддерживать пять представлений по регламенту» выглядит бюрократией: команды без внешней процессной дисциплины (аудиты, сертификация, государственные заказчики) редко выдерживают полноту 4+1 дольше первого квартала. Модель выигрывает там, где полнота описания — требование; там, где документация нужна «для себя», её обычно обрезают до двух-трёх представлений.

4+1: пять диаграмм требуют поддержки #

Каждое представление — отдельный артефакт, который должен поддерживаться в актуальном состоянии синхронно с остальными и с кодом. Изменение одной интеграции может затронуть Logical, Process и Physical одновременно; на практике представления обновляются неравномерно, и документ рассыпается на части разной степени достоверности — читатель не знает, чему верить. Проблема усугубляется тем, что классические CASE-инструменты не давали «одной модели — многих представлений» с автоматической согласованностью.

4+1: слабо отражает эволюцию #

Модель описывает архитектуру как статичный снимок: пять представлений «как устроено» не отвечают на вопрос «как это менялось и почему». Решения об эволюции фиксируются другими инструментами — теми же ADR, — а сами представления не дают места для версионирования и истории; обновлённая диаграмма просто затирает предыдущую.

Общий минус: диаграммы устаревают #

Общая беда обеих моделей — и любой архитектурной документации — в том, что диаграммы отрываются от кода: разработка меняет систему каждый день, а диаграмма обновляется «когда-нибудь». Устаревшая диаграмма вреднее отсутствующей — она уверенно врёт. Лекарство известно и проверено: diagram-as-code — диаграммы хранятся в репозитории рядом с кодом, меняются в тех же pull request’ах, ревьюятся теми же людьми; генерация из кода там, где возможно (уровень Code, API-контракты); периодические архитектурные ревью, где диаграмма сверяется с реальностью. В терминах эволюционной архитектуры актуальность документации может выступать fitness-функцией: проверка «диаграмма обновлена вместе с изменением» встраивается в процесс наравне с тестами.

Связанные статьи #

• Введение в архитектуру — базовые понятия архитектуры ПО, в контекст которых встают модели описания.
• High-Level Design — уровень проектирования, который практически совпадает с Context и Container уровнями C4.
• Low-Level Design — детальное проектирование, соответствующее уровням Component и Code.
• Architecture Decision Records — фиксация решений «почему так»; дополняет диаграммы C4/4+1, показывающие «что есть».
• TOGAF — корпоративная архитектура и её концепция представлений и точек зрения (views/viewpoints), родственная 4+1.
• Clean Architecture — стиль организации кода, слои которого видны именно на компонентном уровне C4.
• Монолитная архитектура — deployment-стиль: как монолит выглядит на уровнях Container и Deployment.
• Микросервисы — декомпозиция на сервисы: границы сервисов становятся контейнерами на уровне 2.
• System Design — процесс проектирования систем, движущийся по уровням C4 от контекста к компонентам.
• Эволюционная архитектура — управление изменениями; актуальность диаграмм как fitness-функция.