C4-модель (Context, Containers, Components, Code) — отдельная лёгкая нотация для описания архитектуры программных систем через согласованный набор диаграмм и текстовых пояснений. На проекте она закрывает вопрос «как устроена наша система и с чем она интегрируется» — до уровня контейнеров деплоя и, при необходимости, внутренней структуры — без перегруза UML или полного стека ArchiMate. Заметка завершает серию 06.03: C4 не входит в стандарт ArchiMate, а дополняет его там, где системному аналитику нужна системная архитектура ПО, а не enterprise-модель предприятия — см. 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).

1. Суть темы

C4-модель предложена Simon Brown как способ сделать архитектуру понятной разным аудиториям — бизнесу, аналитикам, разработчикам, эксплуатации — через zoom-in от системы в ландшафте организации до модулей внутри одного контейнера. Четыре базовых уровня задают иерархию абстракции; каждый элемент верхнего уровня раскрывается на следующем как «чёрный ящик», который можно детализировать отдельной диаграммой. Аудитории и ожидания стейкхолдеров учитывайте через 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).

Граница этой статьи:

В зоне этой статьиВынесено в соседние заметки
Уровни C4, элементы нотации, принципы «just enough architecture»Слои и viewpoints ArchiMate — 06.03.01 Мотивационный слой, 06.03.02 Бизнес-слой, 06.03.03 Прикладной и технологический слои, 06.03.04 Взаимосвязи и точки зрения (Viewpoints)
Динамика на уровне контейнеровДетальные sequence/communication — 06.01.03 Диаграммы взаимодействия (Sequence, Communication)
Бизнес-процессы и потоки работ06.02.01 Потоки, шлюзы, события, 03.04.01 BPMN 2.0 - введение и основы
Контекст системы как артефакт требований03.01.02 Моделирование контекста системы (Context Diagram)
Протоколы и контракты между контейнерами03.05.02 Синхронные протоколы (REST, gRPC, GraphQL), 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)

C4 не заменяет ArchiMate, BPMN или UML — она фокусируется на ПО: границы системы, контейнеры исполнения, логическая структура и ключевые сценарии. Для системного аналитика это практичный инструмент на старте проекта, при согласовании as-is/to-be и при подготовке к оценке интеграций и нефункциональных требований (НФТ).

flowchart TB
    subgraph levels [Уровни абстракции C4]
        L1[System Context<br/>система в окружении]
        L2[Container<br/>контейнеры внутри системы]
        L3[Component<br/>компоненты внутри контейнера]
        L4[Code<br/>классы и модули]
    end
    L1 -->|zoom-in| L2
    L2 -->|zoom-in| L3
    L3 -->|zoom-in| L4

Принцип «just enough architecture»: не все уровни обязательны для каждой системы. Минимум для большинства проектов — context + container; component и code добавляют по запросу команды или для проблемных зон.

C4 System Context и context diagram из SA-практики

03.01.02 Моделирование контекста системы (Context Diagram) и System Context в C4 решают близкую задачу — зафиксировать границу системы и внешние взаимодействия — но это разные артефакты, а не дубликаты одной диаграммы в двух нотациях.

КритерийContext diagram (SA)C4 System Context
ФокусГраница решения в scope требований, акторы из BRD/SRSSoftware system как единица ПО с владельцем и пользователями
ДетализацияЧасто привязана к формулировкам требованийЖёстче: одна целевая system, без внутренностей
АудиторияАналитик, PM, заказчик на этапе требований+ архитекторы и разработчики как вход в container

Правило выбора на проекте:

  • Стандарт проекта задаёт одну «истину» о границе — либо context diagram в пакете требований, либо C4 context в архитектурном репозитории. В смешанных командах владельца фиксируйте явно — см. 00.02 Бизнес-анализ vs Системный анализ vs Требования.
  • Если нужны обе: context diagram — в Vision/SRS как артефакт scope; C4 context — техническое уточнение той же границы для команды разработки. Синхронизируйте имена акторов и внешних систем; расхождения — в ADR или глоссарии (10.01.14 Шаблон глоссария и словаря данных).
  • На старте выберите владельца артефакта (SA или архитектор) и триггер обновления (изменение scope, новая интеграция, релиз). Без этого получите две версии границы после первого спринта.

Несколько продуктов и общая платформа

Правило «одна software system на diagram set» сохраняется, но на landscape и в program-level обзоре часто несколько систем с общими сервисами (API gateway, shared DB, identity platform).

Когда выделять вторую software system:

  • Отдельный владелец продукта, roadmap и бюджет; команда отвечает за свой релизный цикл.
  • Разные пользовательские контракты — отдельный SLA, отдельный домен данных с собственным master data.
  • Система продаётся или сдаётся заказчику как самостоятельный продукт, даже если технически сидит на общей платформе.

Когда оставить одну system и вынести shared-сервис наружу:

  • Общий gateway, SSO, мониторинг — external system или инфраструктурный container внутри одной system, если платформа не продукт для других команд.
  • Suite «одного заказчика» (CRM + биллинг + портал) с единым контрактом — одна software system на container-набор; связи между модулями — внутренние container-to-container, не landscape.

Landscape рисуйте, когда нужен обзор ≥2 software systems и их межсистемных интеграций. Не смешивайте landscape и context одной system на одном листе без легенды.

2. Ключевые понятия

Элементы модели

ЭлементСутьТипичный пример
Software systemВысокоуровневая единица ПО, которую строит команда; имеет владельца и пользователей«Портал самообслуживания», «Сервис биллинга»
PersonЧеловек или роль, использующая системуКлиент, оператор КЦ, администратор
External systemСистема вне границ описываемого ПОERP, платёжный шлюз, партнёрский API
ContainerЕдиница исполнения и деплоя: приложение, БД, брокер сообщений, SPA, mobile app — то, что можно отдельно развернуть и масштабироватьWeb API, PostgreSQL, Kafka, React SPA
ComponentЛогическая группировка внутри контейнераМодули монолита, bounded context внутри сервиса
CodeУровень классов, файлов, пакетовUML class diagram, структура пакетов

В C4 для людей используйте Person, а не «Actor»: термин Actor пересекается с UML и use case — на одном проекте разведите «Person (C4)» и «Actor (UML)» в глоссарии.

Component и границы container пересекаются с декомпозицией «подсистема / модуль» из 03.01.03 Декомпозиция системы на подсистемы и модули и с DDD (03.06.02 Основы Domain-Driven Design): bounded context может быть container (отдельный сервис) или component (модуль внутри монолита). Решение фиксируйте в ADR, а не только на диаграмме.

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

Четыре базовых диаграммы

  1. System Context — одна целевая software system в центре, люди и внешние системы вокруг, основные интеграции; без внутренней структуры.
  2. Container — внутренности системы: контейнеры, технологии (в подписях), протоколы и API между ними и с внешним миром.
  3. Component — разрез одного container: компоненты и зависимости внутри него.
  4. Code — детализация одного component (часто UML class diagram). На практике редко рисуют вручную — отдают IDE и автогенерации.

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

ДиаграммаНазначениеКогда нужна SA
System LandscapeНесколько связанных software systems в организацииКарта продуктового ландшафта, program-level обзор
Dynamic / InteractionСценарий во времени на уровне context или containers3–5 критичных сквозных сценариев: заказ, платёж, синхронизация с ERP
DeploymentMapping контейнеров на инфраструктуру: узлы, среды, зоныSLA, DR, сетевые сегменты, обсуждение НФТ

Dynamic-диаграмма на уровне контейнеров не дублирует sequence-диаграмму UML — она остаётся на более высоком zoom и показывает, какие контейнеры участвуют в сценарии, а не вызовы методов внутри сервиса.

Граница BPMN и Dynamic C4: BPMN описывает бизнес-поток — кто что делает, шлюзы, события, роли. Dynamic C4 начинается там, где сценарий переходит в обмен между контейнерами ПО: «шаг „отправить в ERP“» в BPMN → на dynamic C4 — стрелка Portal API → ERP Adapter с протоколом. Не дублируйте каждый task BPMN на dynamic; возьмите сквозной happy path и точки handoff к внешним системам. Детали процесса — в 03.04.01 BPMN 2.0 - введение и основы, обмен контейнерами — здесь.

Принципы нотации

  • Иерархия и согласованность: элемент на context-диаграмме = «чёрный ящик» на container; container на context = box на component.
  • Подписи на связях: не только стрелки — назначение («отправляет заказы»), протокол («REST/JSON»), при интеграциях — data ownership (кто master, кто replica).
  • Легенда и ключ: типы элементов, цвета — по соглашению команды, зафиксированному в глоссарии.
  • Документ = диаграмма + текст: ADR, quality attributes, риски — рядом с C4, не вместо них; см. 10.01.13 Шаблон архитектурного решения (ADR).
  • Одна software system на набор диаграмм; для ландшафта — отдельная landscape-диаграмма.
  • Визуальный канон: примеры ниже на Mermaid — для логики, не для печати и не как корпоративный стандарт. Официальные формы элементов — в Structurizr и на c4model.com/#Notation; для согласованных диаграмм используйте их или экспорт из инструментов моделирования с C4-шаблонами.

Минимальный набор представлений (viewpoints для C4)

Это локальные срезы container/context под аудиторию — не путать с ArchiMate Viewpoint как ограничением метамодели (06.03.04 Взаимосвязи и точки зрения (Viewpoints)). Для C4 достаточно отфильтрованных копий, а не одной «spaghetti»-диаграммы:

ПредставлениеЧто показыватьТипичная аудитория
Integration-onlyТолько контейнеры и внешние системы + подписи протоколовSA, интеграторы
Security / trust zonesКонтейнеры в DMZ / private subnet, границы доверия — см. чеклист нижеИБ, эксплуатация
Data flowПотоки с указанием master data и чувствительных данныхSA, DBA, комплаенс
DeploymentContainer → Node/средаDevOps, NFR по availability и DR

Минимальный чеклист для security-view на container:

Связь C4 и ArchiMate

ArchiMate описывает предприятие сквозно; C4 не маппится один-к-одному — другая гранулярность и аудитория. Условное соответствие (зафиксируйте в глоссарии, если в организации обе нотации):

C4ArchiMate (ориентир)Уровень диаграммы
PersonBusiness Actorcontext / landscape
External systemApplication Service, Technology Service; внешний Application Componentcontext
ContainerApplication Component (прикладной слой)container
Container (размещение)Node, Device, Networkтолько deployment, не container-диagram
ComponentApplication Component (детализация внутри одного application)component

Пример external system: партнёрский REST API → на context рисуете external system «Партнёрский биллинг»; в ArchiMate — Application Service (контракт API) + внешний Application Component (система партнёра как чёрный ящик). Это не «или-или», а два элемента одной интеграции.

Node не рисуйте на container-диаграмме — элемент технологического слоя. Практичная комбинация для SA: context/container в C4 + мотивация и процессы в ArchiMate/BPMN. Владелец синхронизации, частота ревью и триггер обновления — в проектном соглашении; иначе модели разойдутся после первого релиза.

НФТ на container vs deployment

Класс НФТ (см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты)Где фиксировать в C4
Latency, throughput между сервисамиПодписи связей на container + dynamic
Availability, RTO/RPO, резервированиеDeployment + текст к ADR
Сегментация сети, DMZ, шифрование на границе периметраDeployment или security-view container
Масштабирование отдельного приложенияПодпись container; топология реплик — deployment

Container готовит перечень где обсуждать НФТ; числа и SLA — в спецификации НФТ, не на стрелках диаграммы.

Structurizr и «архитектура как код»

Structurizr — экосистема автора C4: DSL/workspace, единый источник модели и генерация диаграмм. Снижает рассинхрон «картинка vs реальность» после рефакторинга. Альтернативы: PlantUML C4, Mermaid (ограниченная поддержка), IcePanel, шаблоны в draw.io и draw.io/Lucidchart.

3. Как применяется в работе аналитика

Когда применять C4 — и когда достаточно context diagram

C4 оправдан, если:

  • Старт проекта или описание as-is / to-be границ системы и интеграций.
  • Нужно согласование с заказчиком и командой разработки до детального проектирования — раньше, чем sequence на уровне классов; подача результатов — 09.04 Презентация результатов анализа и сторителлинг.
  • Есть несколько контейнеров, внешние интеграции, очереди, БД — container-диаграмма даёт карту ландшафта.
  • Готовитесь к оценке, рискам интеграции (08.05 Управление рисками на этапе анализа), НФТ — latency, availability, зоны безопасности.
  • Обсуждаете deployment при SLA, DR и сетевых сегментах.

C4 не стоит разворачивать, если:

  • Один модуль или монолит без внешних интеграций, срок — одна фича или небольшой инкремент.
  • Аудитория — только заказчик на уровне scope; технической декомпозиции ещё нет.

В таких случаях достаточно context diagram и пары абзацев в SRS (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)). Container добавляйте, когда появляется реальная потребность в карте деплоя и протоколов.

Место C4 в SDLC и Agile

По 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC) и 05.02 Scrum и Kanban (аналитик в Agile):

МоментЧто рисовать
Спринт 0 / discovery, архитектурный runwaySystem Context + черновой container; baseline до первых story с интеграциями
Refinement эпика с интеграциямиОбновление container, dynamic для нового сценария
Инкремент одной фичи без новых системЧасто хватит правки подписи на существующем container
Program-level / несколько продуктовLandscape отдельно от context одной system

C4 — не обязательный артефакт каждого спринта; триггер — появление или изменение границы system, нового container или внешней интеграции.

Место C4 в пакете документов

По 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD):

ДокументРоль C4
Vision & Scope / BRDContext (или ссылка на него) как иллюстрация границы решения
SRS / архитектурное приложениеContext + container как baseline; dynamic для критичных сценариев
ADRРешения по границам container, протоколам — текст; C4 — иллюстрация к [[10.01.13 Шаблон архитектурного решения (ADR)

C4 не заменяет SRS и не дублирует OpenAPI — это каркас, на который вешают детальные артефакты.

Типовой workflow SA

flowchart TD
    A[Workshop: акторы и граница software system] --> B[System Context C4]
    B --> C[Согласование с бизнесом]
    C --> D[Container diagram<br/>технологии и протоколы]
    D --> E[Dynamic: 3–5 критичных сценариев]
    E --> F{Нужна детализация?}
    F -->|да| G[Component для проблемного container]
    F -->|нет| H[Deployment + ADR + трассировка]
    G --> H
  1. Workshop: Person, external systems, scope «нашей» software system — граница контракта или продукта; см. 02.01.04 Определение границ решения (Scope Modelling), 02.02.02 Воркшопы, фасилитация и совместные сессии, 09.02 Проведение эффективных встреч и воркшопов.
  2. System Context (C4) — или context diagram, если проект выбрал нотацию из 03.01.02 Моделирование контекста системы (Context Diagram) как единственную «истину»; далее согласование с бизнесом. BPMN и use case — отдельные артефакты (03.02.01 Диаграмма прецедентов (Use Case Diagram)), не смешивайте нотации на одном листе без легенды.
  3. Container diagram с технологиями и протоколами — вход для НФТ, security zones, потоков данных.
  4. Dynamic diagram для критичных сценариев; трассируйте к BPMN-процессу: сценарий процесса → dynamic C4.
  5. Component — по запросу команды или для проблемных зон; не обязательно на весь монолит.
  6. Хранение: Confluence/Markdown + версионирование; при росте — Structurizr или PlantUML.

Артефакты рядом с C4

АртефактЗачем
ГлоссарийЧто в вашем продукте считается «системой» vs «контейнером»; см. 10.01.14 Шаблон глоссария и словаря данных
Integration catalogСписок интеграций, выведенный из context/container
Матрица трассировкиUser story / FR → container; сценарий BPMN → dynamic C4; см. 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки
ADRРешения по границам, протоколам, выбору контейнеров

В матрице трассировки для C4 достаточно колонок: ID требования → container/component → связь на диаграмме (имя стрелки). Не дублируйте текст требования на диаграмме.

Container-диаграмма как основа интеграционной спецификации

На container-уровне фиксируйте для каждой связи — каркас, не полная спецификация:

На C4 (обязательно)В контракте / шаблоне (детально)
Назначение потока, направление, sync/asyncОперации, схемы, коды ответов / схема события
Протокол и формат (REST/JSON, Kafka)Endpoints, AsyncAPI channels, topic/partition
Владелец контракта, data ownershipПоля payload, валидация, SLA
Ссылка «см. спецификацию X»10.01.04 Шаблон спецификации REST API (sync), 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) (async), 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)

C4 отвечает на «кто с кем и зачем»; OpenAPI/AsyncAPI и шаблоны — на «как именно». Мост к интерфейсам и интеграциям.

Async и event-driven: на стрелке указывайте брокер и topic/event name (например, Kafka / order.created), не абстрактную «async». Паттерны outbox, порядок доставки, идempotency — в спецификации и 03.05.06 Event-Driven Architecture, не на диаграмме целиком, но имя канала на container обязательно, иначе EDA-ландшафт нечитаем.

Критерии «готово» для ревью

  • На context видны все внешние акторы и системы из scope требований.
  • На container — каждый путь данных из критичных сценариев; нет «магических» стрелок без подписи; async — с broker/topic.
  • Одна software system на workspace/diagram set; для ландшафта — landscape; критерии второй system — см. подраздел «Несколько продуктов и общая платформа».
  • Диаграммы сопровождены текстом: назначение системы, ключевые решения, ссылки на ADR.
  • При обсуждении SLA и отказоустойчивости есть deployment или явная отсылка к инфраструктурной документации.
  • Для каждой внешней интеграции — ссылка на контракт или «TBD» с владельцем.
  • Согласование: ключевые стейкхолдеры приняли baseline; зафиксированы версия, дата, статус (draft / approved) — по смыслу 02.04.01 Верификация и валидация (V&V) и 08.04 Рецензирование и инспекции (техники Фейгана).
  • Нотация: для корпоративного архива — Structurizr, PlantUML C4 или инструмент с официальными формами; Mermaid-flowchart из примеров — только черновик, не этalon.

Пример фрагмента context (логика, не каноническая нотация)

flowchart LR
    User[Клиент]
    Admin[Администратор]
    Portal[Портал самообслуживания]
    ERP[Корпоративная ERP]
    Pay[Платёжный шлюз]

    User -->|оформляет заявки| Portal
    Admin -->|управляет справочниками| Portal
    Portal -->|синхронизация заказов REST| ERP
    Portal -->|инициирует оплату HTTPS| Pay

На следующем уровне «Портал» раскрывается в web SPA, API, БД, брокер — каждый как отдельный container с технологией в подписи. Официальный вид person/system — см. c4model.com/#Notation.

4. Типовые ошибки и ограничения

Ограничения модели

  • Не заменяет BPMN — потоки работ и исполнимые процессы; не заменяет полный ArchiMate — стратегия, мотивационный слой; не заменяет UML для детального OO-дизайна.
  • Слабая формальная семантика по сравнению с UML/ArchiMate — соглашения внутри команды обязательны.
  • Code level редко окупается в документации; высокий риск устаревания.
  • Не описывает организационные границы — команды, бюджеты, RACI; только техническая и логическая структура ПО.
  • Масштаб: на landscape/container легко получить «spaghetti» без фильтров — используйте минимальный набор представлений из §2.

Типичные ошибки

ОшибкаПоследствиеКак избежать
Путать Container (C4) и Docker containerНеверные границы при оценке и деплоеЗафиксировать определение в глоссарии
Рисовать внутренности на context (БД, микросервисы)Аудитория теряет фокус, ломается иерархияContext — только «чёрные ящики»
Несколько software systems на одной context без landscapeНепонятная граница ответственностиОдна system на diagram set или landscape; критерии split — см. подраздел «Несколько продуктов и общая платформа»
Каждый микросервис = отдельная software systemЛомается landscape, ownership и program-обзорSoftware system — продукт/контракт; микросервисы — containers внутри одной system
Node ArchiMate на container-диаграммеСмешение прикладного и технологического слояNode только на deployment; mapping — см. §2
Component-диаграмма на всю систему сразуПерегруз, нет фокусаОдин container на diagram
Диаграммы без текста и без связи с требованиями«Картинка для презентации», быстро устареваетADR, матрица трассировки, описания
C4 вместо OpenAPI / AsyncAPIНет контракта для разработки и тестовКаркас на container + шаблон API или Kafka
Async-стрелка без broker/topic/event nameEDA-ландшафт нечитаем, дубли интеграцийПодпись Kafka / event.name; детали — в 03.05.06 Event-Driven Architecture
Копирование физической топологии (VPC, k8s namespaces) в containerСмешение логики и инфраструктурыЛогические границы на container; инфра — на deployment
Игнор deployment при обсуждении SLA и DRНФТ «висят в воздухе»Deployment-диаграмма или явная ссылка
Устаревание после рефакторингаДве версии правдыМодель как код, ревью при изменении архитектуры
Две «истины» C4 context и context diagramРасхождение scope и архитектурыПравила из §1: один владелец, триггеры sync, глоссарий

Связи с другими разделами базы

Источники и дополнительные материалы

Официальные материалы и документация

Статьи и доклады

Книги