Что представляет собой архитектурный подход С4
Диаграмма С4 — способ визуализации архитектуры проекта, отражающая структуру системы на разных уровнях.
Представьте, что вы — аналитик, проектирующий будущую систему или описывающий уже существующую. Вам нужно объяснить, как работает сервис:
- Менеджеру/руководству — в двух словах.
- Новому разработчику — подробнее.
- Команде DevOps — с техническими деталями.
Хотя особую популярность на практике диаграмма приобрела относительно недавно, архитектурный подход C4 был создан консультантом по разработке программного обеспечения Саймоном Брауном больше десяти лет назад, чтобы сделать архитектуру понятной всем членам команды — от разработчиков до менеджеров. Основной проблемой Браун видел то, что в попытке объяснить архитектуру системы разработчики используют разрозненные обозначения, стрелки и графические изображения, разную, иногда противоречащую, терминологию, смешанные абстракции. Классические UML-диаграммы всё еще востребованы и решают свои задачи, но не демонстрируют визуально общий взгляд на архитектуру проекта.
Кстати, отсутствие единообразного подхода — проблема, актуальная для современных команд разработки. Подход заменил сложные схемы простыми многоуровневыми диаграммами, которые каждый может понять на своем уровне технической погруженности в детали проекта.
С4 — это как Яндекс Карты для проекта: можно посмотреть на весь город (систему) целиком, нажать плюсик и приблизить до отдельного дома (модуля), а приблизив еще — разглядеть этажи и квартиры (классы).
Кстати, такую же аналогию с картой и увеличением масштаба и приводит Браун для объяснения сути концепции архитектурного подхода С4.
Четыре С: из каких уровней состоит диаграмма
Название диаграммы С4 — сокращение от четырех английских слов, начинающихся на букву с: context, container, component, code — по сути, это и есть 4 уровня детализации и масштабирования.
Уровень 1. Context diagram — диаграмма контекста
Представьте, что вы смотрите на город с высоты птичьего полета и видите:
- Крыши крупных зданий (ваша система).
- Дороги и развязки между ними (интеграции).
- Окрестности (внешние сервисы).
Контекстный уровень — это самый высокий уровень абстракции, погружающий — простите за тавтологию — в контекст проекта, описывающий общую бизнес-логику, ключевые программные системы и главных пользователей, а также взаимодействие с внешними системами. На этом уровне можно считать основные пользовательские сценарии использования, а также понять, какие системы/интеграции используются для выполнения целей проекта.
Уровень 2. Container diagram — диаграмма контейнеров
Вы всё еще «летите» над городом, но уже ниже и можете различать в рамках одного комплекса зданий отдельные строения, их расположение друг от друга. Мы — на уровне контейнеров.
В контексте программных систем контейнерами можно считать:
- Веб-приложение.
- Backend.
- API и иные интеграции.
- Базу данных и иные, например облачные хранилища и файловые системы.
- Кеш.
Контейнер в C4 — это единица развертывания: все его элементы (компоненты — об этом далее) работают в одном процессе (например, серверное приложение, мобильное приложение или база данных). Если контейнер обновляется — меняется вся его внутренняя логика.
Уровень 3. Component diagram — диаграмма компонентов
Мы успешно приземлились и зашли внутрь одного из больших зданий. У него есть крыша, стены, окна, внутри есть комнаты, двери и лестницы, узел инженерных коммуникаций, вытяжка и т. п.
Точно так же на уровне компонентов можно рассмотреть проект. Тип компонентов будет зависеть от используемого языка программирования.
Например, в объектно ориентированных ЯП (Java, C#, C++ и других) компонент состоит из классов и интерфейсов. А модуль JavaScript — из ряда объектов и функций.
Уровень 4. Code — код
Как здание, в котором мы находимся, состоит из «кирпичиков», цемента и других стройматериалов, компоненты системы включают один или несколько элементов кода.
Личное наблюдение: практически всегда упоминание об этом уровне детализации сопровождается пометкой «необязательный уровень», «его редко кто проектирует», по крайней мере, в своей практике я не встречала детализации на таком слое.
Сам Саймон Браун, автор методологии C4, предупреждает, что диаграммы четвертого уровня (отражающие структуру кода) особенно быстро теряют актуальность в условиях активной разработки программного обеспечения, и рекомендует «не создавать их вообще» или создавать для объяснения особо сложных ситуаций.
Кажется, как будто уже пора переименовывать диаграмму в С3.
Преимущества и недостатки диаграммы С4
Плюсы:
- Диаграмма удобна для восприятия.
- Понимание доступно специалистам каждого уровня технической подготовки.
- Ее можно масштабировать и иметь представление обо всей структуре.
А минусы будут?
C4 отлично показывает структуру системы, но не подходит для отслеживания пути потока запросов: для этого нужны sequence-диаграммы (о них я писала в этой статье). Автор нотации, Саймон Браун, подчеркивает: C4 и UML-диаграммы решают разные задачи. Как говорится, «за что боролись, на то и напоролись» — если отходить от UML, то и динамику процессов придется смотреть в других инструментах. В целом sequence можно интегрировать в С4, получится интерактивный и живой взгляд на архитектуру проекта.
Кроме того, в сложных системах C4-диаграмма может стать перегруженной, поэтому лучше дробить на подсистемы.
Инструменты для рисования диаграммы С4
Прежде чем показать, как на практике сделать свою С4, пару слов про инструменты:
Draw.io/Diagrams.net — бесплатно, просто, есть шаблоны C4.
И если в прошлой статье я писала, что Draw.iо — это отличный инструмент для рисования сиквенс-диаграмм, чтобы пострадать и потратить кучу нервных клеток, то в случае с С4 это действительно достаточно рабочий инструмент.
Miro или его аналоги — также есть шаблоны и удобно использовать для совместной работы.
Лично мне Miro приятнее по визуалу и инструментам, чем Draw.iо.
Для более продвинутых есть специальные инструменты для проектирования С4 кодом:
PlantUML — текстовая нотация, проект можно хранить в репозитории.
Навести красоту в диаграмме будет несколько сложнее, чем в приложениях для графического рисования: здесь аргумент за четкость линий, как в сиквенсах, уже работает меньше.
Structurizr — специализированный инструмент от автора методологии.
Для последнего как минимум нужно сделать подготовительные шаги — создать репозиторий, чтобы потрогать ручками нотацию, быстро не получится.
Хотя на деле, если один раз посидеть, покопаться и разобраться с синтаксисом, получится классная инвестиция в рабочий проект, которая потом сэкономит много времени, и будет удобнее поддерживать архитектурную схему в актуальном состоянии.
В этой статье для быстрого старта посмотрим, как рисовать в графических редакторах.
Основные элементы диаграммы С4
Нотация довольно интуитивная:
- Пользователи (внутренние и внешние).
- Штрих-стрелки для отображения связи между элементами.
- Прямоугольники для обозначения систем.
- Контейнеры для отображения хранилищ.
Самый распространенный вариант — делать диаграмму серо-голубо-синюю: саму систему обозначать светло-голубым, пользователей — темно-синим, а внешние системы — серым цветом.
Но сам автор нотации пишет: нет каких-то строгих правил, главное — придерживаться единообразия и сопровождать диаграмму легендой, поясняющей используемые обозначения. Цвет стрелки должен быть такой же, как у родительского элемента (от которого она исходит), а элементы внешней системы должны отличаться по цвету.
Диаграммы должны иметь четкий заголовок с указанием типа и назначения, все элементы — явные метки и краткие описания их ролей, а для контейнеров/компонентов — обязательное указание технологий реализации.
Разберем на примере
Итак, предположим, у нас есть фитнес-приложение FitTracker — наглядный пример с понятными функциями и достаточно сложной архитектурой для демонстрации всех уровней С4.
Для начала определим бизнес-логику приложения, выделим основные функции:
- Учет потребленных и потраченных калорий.
- Дневник тренировок (кардио, силовые).
- Трекер воды.
- Интеграция с умными часами.
- Генерация отчетов для отслеживания динамики.
Уровень контекста (Context)
На этом этапе определим, кто и каким образом взаимодействует с системой:
- Вводит данные о питании.
- Отслеживает тренировки.
- Смотрит статистику.
FitTracker –> Умные часы: синхронизация пульса/шагов.
FitTracker –> База данных питания: получает информацию о продуктах.
Уровень контейнеров (Containers)
Определим, из каких крупных блоков состоит система, а также границы системы обозначим прямоугольником и добавим ему заголовок.
Описание контейнеров:
- Мобильное приложение (iOS/Android) — интерфейс для пользователей.
- Backend API — обрабатывает логику, считает калории, хранит данные.
- База данных — PostgreSQL (пользователи, тренировки, вода, еда).
- Кеш (Redis) — ускорение загрузки статистики.
- Внешние сервисы — API умных часов, база продуктов, почта.
Уровень компонентов (Components)
Рассмотрим на примере детализации контейнера Backend API:
Сервис аутентификации:
Регистрация/логин через соцсети
Сервис калорий:
Расчет нормы (по весу/активности)
Учет потраченных калорий
Сервис тренировок:
План занятий
Прогресс по упражнениям
Сервис уведомлений:
Push-напоминания
Еженедельные отчеты
Кроме того, можете проверить готовую диаграмму С4, используя чек-лист самопроверки от автора нотации.
Мотивация вместо заключения
Модель С4 приобретает большую популярность, особенно с ростом использования микросервисных архитектур. C4 — это не просто диаграммы, это новый взгляд на архитектуру проекта. Чем раньше вы начнете применять этот подход, тем меньше «архитектурного долга» накопите в проекте. Попробуйте нарисовать С4 для своего проекта уже сейчас, желаю удачи!
