Привет! Меня зовут Яна, я – старший системный аналитик в компании «Совкомбанк Технологии».
В работе чаще всего сталкиваюсь со сложными распределенными системами, большим количеством интеграций и микросервисной архитектурой. На одном из недавних проектов удалось применить модель C4, впоследствии ставшей одним из основных инструментов для проектирования, анализа и коммуникации между участниками команды – именно этим практическим опытом хочу поделиться в статье.
В современном мире системному аналитику в ИТ-проектах все чаще приходится сталкиваться со сложными распределенными системами, большим количеством интеграций и различными смежными командами разработки. Архитектура таких систем быстро усложняется, требования к ним увеличиваются, а темп разработки растет.
В условиях, когда система состоит из десятков сервисов и микросервисов, очередей, баз данных и внешних интеграций, опираться на сухое техническое задание становится сложно. Требования без визуального представления архитектуры теряют наглядность, а команда все чаще упирается в разное понимание контекста задачи.
В подобных ситуациях архитектурные схемы перестают быть инструментом только архитектора и все чаще становятся повседневным инструментом системного аналитика.
Если говорить про проектирование, то многие вспомнят язык моделирования UML (Unified Modeling Language) с его разнообразием диаграмм. В этой статье расскажу еще об одном, менее популярном, но не менее удобном подходе к описанию архитектуры – модели C4. Она позволяет системно и последовательно визуализировать архитектуру на разных уровнях детализации.
Далее рассмотрим, как системный аналитик может использовать C4 в повседневной работе, какие уровни модели наиболее полезны и какую практическую ценность это приносит команде.
Архитектурная модель в системном анализе
В последние годы наблюдается устойчивая тенденция перехода от монолитных архитектур к микросервисным. Это касается процессов не только крупнейших технологических компаний, но и более мелких.
В таких условиях особенно важно иметь единую, понятную и масштабируемую модель архитектуры, которая позволит:
Рассматривать систему с разных уровней: от общего контекста взаимодействия с пользователями и внешними системами до детального разбора внутренних компонентов.
Наглядно отображать сложные интеграции, так как в микросервисных архитектурах число взаимодействий между сервисами растет быстро и без визуализации легко запутаться в реализованных зависимостях.
Системному аналитику необходимо не только понимать бизнес-логику, но и хорошо ориентироваться в архитектурной структуре системы. Это поможет корректно формировать требования и оценивать влияние изменений.
Что такое C4?
C4 – это модель описания архитектуры программных систем, предложенная Саймоном Брауном. Основная идея заключается в том, чтобы описывать систему на нескольких уровнях детализации, каждый из которых отвечает на свой набор вопросов.
Модель включает четыре уровня:
Context – общий контекст системы, пользователи и внешние системы
Container – основные контейнеры: сервисы, базы данных, очереди, приложения
Component – компоненты внутри сервисов
Code – уровень реализации, который обычно находится вне зоны ответственности аналитика
Для системного аналитика особенно полезны первые 2-3 уровня, так как именно они помогают связать бизнес-логику, требования и техническую реализацию. В данной статье уделим больше внимания именно им.
Уровни 3-4 наиболее актуальны разработчикам, но для общего контекста полезны всем участникам команды.
Поговорим детальнее о каждом уровне диаграммы C4, из каких элементов она строится.
В моделях C4, как и в других нотациях, есть своя «азбука», способствующая унификации подхода. При построении C4-диаграмм используется ограниченный и достаточно простой набор элементов, что позволяет не перегружать схемы и обеспечивать читаемость.
Базовые элементы C4:
Person – пользователь или роль, взаимодействующая с системой
System – программная система или продукт
Container – исполняемая единица: сервис, приложение, база данных, очередь
Component – логическая часть внутри контейнера
Relationship – связи, то есть взаимодействие между элементами
Разный набор элементов используется на разных уровнях. В качестве примера рассмотрим систему, реализующую интернет-магазин с микросервисной архитектурой, включающей: веб-приложение, сервис заказов, сервис платежей, складскую систему и несколько внешних интеграций. Рассмотрим, как можно отобразить архитектуру данной системы на каждом уровне C4.
Context-диаграмма – 1 уровень модели C4
Context-диаграмма (диаграмма контекста) описывает систему на самом верхнем уровне: кто является пользователем, какие внешние системы участвуют во взаимодействии и где проходят границы зон ответственности.
На практике именно на этом уровне часто выявляются неочевидные зависимости: интеграции, о которых команда знает, но нигде не фиксирует, или внешние системы, критичные для бизнес-процессов.
Наличие актуальной context-диаграммы позволяет значительно сократить количество уточняющих встреч и быстрее вводить новых участников в проект.
Для системного аналитика этот уровень особенно важен на старте проекта, когда требуется верхнеуровнево спроектировать задачу, реализовать новые интеграции или задокументировать глобальные зависимости между командами и проектами.
Попробуем реализовать context-диаграмму для нашего кейса. На этом уровне нас интересует не внутренняя реализация системы, а ее место в ИТ-ландшафте компании: кто является пользователем, с какими внешними системами происходит взаимодействие и где проходят границы зон ответственности.
В context-диаграмме мы отображаем:
Пользователей:
Покупатель – роль клиента в данной системе
Оператор интернет-магазина – роль сотрудника в данной системе
Основную систему – Best Online Shop – онлайн-платформа для покупки товаров
Внешние системы:
Платежный провайдер – отвечает за обработку онлайн-платежей
Служба доставки – отвечает за организацию доставки заказов
ERP-система – корпоративная система управления ресурсами компании
Также отобразим на схеме связи систем и пользователей для наглядности.
На диаграмме видно, что интернет-магазин взаимодействует с несколькими внешними системами: платежным провайдером, службой доставки и ERP-системой. На этом уровне удобно выявлять критические интеграции, от которых напрямую зависит работоспособность бизнес-процессов.
На практике именно эта диаграмма помогает договориться участникам проекта о зонах ответственности и избежать формулировок вроде «это где-то в другой системе».
Container-диаграмма – 2 уровень модели C4
Container-диаграмма (диаграмма контейнеров) – основной инструмент при работе с микросервисной архитектурой. На этом уровне отображаются ключевые сервисы, базы данных, очереди и способы их взаимодействия.
Зачастую именно container-диаграмма помогает понять, что за кажущейся простой бизнес-логикой может стоять цепочка из нескольких сервисов, очередей и внешних вызовов.
Этот уровень позволяет:
Корректно оценивать влияние изменений
Выявлять скрытые зависимости
Заранее учитывать нефункциональные требования: отказоустойчивость, производительность, масштабируемость
На данном этапе аналитик связывает бизнес-требования с конкретными сервисами, выявляет затрагиваемые компоненты при изменениях, прорабатывает интеграционные сценарии.
Данный уровень модели C4 отлично подходит для создания общего контекста с конкретной командой разработки внутри одного проекта, так как уровень детализации понятен всем участникам команды: от аналитика до тестировщика.
В рамках нашего кейса мы декомпозируем систему Best Online Shop – онлайн-платформу для покупки товаров – и рассмотрим ее на уровне container-диаграммы.
На этом уровне система рассматривается как набор взаимодействующих контейнеров: сервисов, баз данных, брокеров сообщений и пользовательских приложений. Container-диаграмма позволяет связать бизнес-требования с конкретными техническими компонентами и понять, как изменения одного сервиса влияют на другой.
Рассмотрим container-уровень на примере архитектуры интернет-магазина:
Из схемы видно, что система состоит из набора специализированных сервисов заказов, платежей, склада, а также инфраструктурных компонентов – API Gateway и брокера сообщений. Асинхронное взаимодействие через Kafka позволяет ослабить связанность сервисов, повысить отказоустойчивость и масштабируемость системы.
Для аналитика container-диаграмма является отличным инструментом при анализе влияния изменений: по ней легко определить, какие сервисы будут затронуты новой функциональностью, какие интеграционные контракты потребуют доработки и где могут возникнуть риски производительности или отказоустойчивости.
Component-диаграмма – 3 уровень модели C4
Component-диаграмма (диаграмма компонентов) используется реже, но становится особенно полезным при работе со сложной бизнес-логикой или критичными участками системы.
Component-диаграммы хорошо работают при:
Рефакторинге легаси-кода
Внедрении новых сложных бизнес-механик
Анализе причин дефектов и архитектурных ограничений
Для подготовки данного уровня модели C4 аналитик работает совместно с разработчиком. В результате они могут разложить сложные сценарии на логические компоненты, зафиксировать зоны ответственности внутри сервиса, выявить потенциальные узкие места, посмотрев на задачу глубже с разных сторон.
Важно не перегружать component-уровень и использовать его только там, где это действительно оправдано сложностью задачи.
Попробуем декомпозировать контейнер Order Service, отвечающий за обработку платежей на примере component-диаграммы для данного сервиса.
На этом уровне сервис рассматривается как набор логических компонентов, каждый из которых отвечает за свою часть функциональности.
На диаграмме показано, как внутри сервиса заказов распределена ответственность между компонентами: обработка входящих запросов, оркестрация бизнес-логики, расчёт стоимости, резервирование товара и взаимодействие с платёжным сервисом.
Code-диаграмма – 4 уровень модели C4
Code-уровень (диаграмма кода) – самый детальный уровень модели C4, описывающий внутреннюю структуру реализации: классы, модули, пакеты, зависимости на уровне исходного кода.
Как правило, этот уровень находится за пределами зоны ответственности системного аналитика и используется в основном разработчиками и архитекторами при проектировании и рефакторинге кода.
Тем не менее, понимание принципов сode-уровня полезно аналитику прежде всего для осознания границ собственной зоны ответственности и возможности влияния на архитектуру.
На практике участие аналитика на этом уровне проявляется в следующих сценариях:
Разбор сложных дефектов, когда причина ошибки кроется не в логике требований, а во внутренней реализации.
Проработка критически важных бизнес-механик, где важно понимать ограничения текущей реализации.
Анализ легаси-кода, когда архитектурные проблемы напрямую влияют на бизнес-функциональность.
В таких случаях аналитик выступает связующим звеном между бизнесом и разработкой, помогая сопоставить бизнес-логику с технической реализацией и выявить системные ограничения.
Важно отметить, что попытка детально описывать кодовую архитектуру со стороны аналитика часто приводит к избыточной детализации и дублированию документации разработчиков. Поэтому code-уровень следует рассматривать как справочный и использовать точечно: там, где без понимания внутренней реализации невозможно принять верные решения.
Практическое применение
После рассмотрения всех уровней C4 может возникнуть ощущение, что что-то подобное уже использовалось. И правда, между C4 и классическими нотациями бизнес-моделирования, такими как IDEF0, есть концептуальное сходство.
Обе методологии используют принцип иерархической декомпозиции, позволяя последовательно переходить от общего уровня абстракции к детальному. Однако фокус у них различается: IDEF0 описывает функциональную сторону системы и отвечает на вопрос – что именно система делает, тогда как C4 концентрируется на архитектурной структуре и отвечает на вопрос – из каких компонентов система состоит и как организовано взаимодействие.
Касаемо практических сценариев применения, можно выделить несколько процессов, в которых C4 особенно актуальна.
В первую очередь при проектировании новых интеграций C4 помогает наглядно показать, какие сервисы участвуют во взаимодействии, выявить потенциальные точки отказа, а главное согласовать формат взаимодействия между командами и создать общий межкомандный контекст.
Также в процессе онбординга новых аналитиков и разработчиков C4-схемы позволяют им быстро погрузиться в архитектуру системы и её ключевые потоки без изучения сотен страниц документации. А если документации нет, то C4 часто используется как способ «пересобрать» понимание системы и зафиксировать текущее состояние архитектуры, борясь тем самым с устаревшим кодом.
Подводя итог, можно сказать, что в условиях микросервисной архитектуры и растущей сложности систем C4-модель становится не просто архитектурной нотацией, но и полноценным рабочим инструментом системного аналитика, и не только.
C4 позволяет формировать целостное понимание системы, связывать требования с технической реализацией, улучшать коммуникацию между аналитикой, разработкой и архитектурой, снижать количество ошибок и недопонимания. Помогает команде мыслить не отдельными требованиями, а системно, что становится критически важным в современных распределенных проектах.
Расскажите, пробовали ли вы C4 в своей работе? Какие уровни модели используете чаще всего и для каких целей? Или, может, у вас есть свой подход к визуализации архитектуры, который работает лучше?
Делитесь опытом в комментариях – обсудим вместе, как визуализировать архитектуру в эпоху микросервисов.
