На момент написания статьи, модель С4 (C4 model) всё ещё является довольно популярным инструментом для описания архитектуры программных систем. Она состоит из намного меньшего количества элементов, если сравнивать с классическим языком моделирования — UML или новомодным ArchiMate, поэтому процесс изучения проходит намного проще и быстрее. Важно отметить, что модель C4 формально не является языком моделирования. Чтобы таким считаться нужно соответствовать ряду требований — наличие спецификации, должен быть определён синтаксис и семантика. Хотя C4 нельзя ставить в один ряд с другими полноценными языками моделирования, у неё всё равно есть ряд преимуществ.
Модель C4 была создана Саймоном Брауном в период с 2006 по 2011 год. Идея была в изящном разделении архитектуры на четыре разных уровня. Более подробно с историей создания и подробной технической документацией можно ознакомиться на сайте → https://c4model.com/
Я не планировал превращать данную статью в пересказ всего того, что и так можно прочитать у Саймона Брауна на его сайте или книге, а больше уделить внимание собственному опыту и практическим аспектам. Тем не менее, чтобы сформировалось правильное понимание, хотел кратко рассказать про главное.
Идея
Концепцию модели С4 можно легко понять по иллюстрации:
Всё крутится вокруг разбиения архитектуры на четыре уровня абстракции: Context, Container, Component, Code.
- Context — самый верхний уровень, описывает то, как работает система в целом, что-то вроде UseCase диаграмм в UML.
- Container — скорее технический уровень. Например, про веб-сервера, базу данных и так далее.
- Component — про компоненты программы. Например, пакеты, модули или программные библиотеки.
- Code — самый нижний уровень. Например, классы и их наследование, описание структуры данных.
Фактически это и есть краеугольный камень всей модели C4 — 4(четыре) уровня абстракции. Альфа и омега всей концепции. Сейчас, в эпоху бурного развития искусственного интеллекта, когда решение рутинных задач становится всё проще и проще, нам, людям, очень важно уметь формировать в сознании правильную концепцию или, как модно сейчас говорить — ментальную модель, то есть понимание того, как всё работает на самом деле, чтобы потом можно было с этим эффективно работать.
В качестве примера ментальной модели из другой области, можно привести концепцию «трёх деревьев» в git. В документации про git это всего лишь небольшой раздел, но если с ним не ознакомиться, то работать с git-ом становится неприятно и сложно, через какое-то время можно столкнуться с ситуацией, когда будет ощущение полного хаоса и непонимания того, что происходит с файлами и версиями.
Также и с моделью C4, при всей простоте идеи, заложенной в концепцию, к сожалению, в интернете встречаются примеры диаграмм, несоответствующие базовой идеи — перемешаны элементы разных уровней, используются неправильные элементы и связи между ними. Получается, что люди берут только внешние атрибуты, сохраняют визуальный стиль, но не в полной мере следуют основной концепции.
Для архитектурных диаграмм всё-таки важно, чтобы они были сделаны верно и использовались правильным способом.
Представьте, что кому-то поручили разработать план небольшого коттеджного посёлка. Если малоопытный архитектор перепутает масштаб, обозначения для дорог и линий электропередач, то потом можно легко попасть в неприятности.
Аналогично в архитектуре программных систем.
Например, вы работаете над Context диаграммой. Не следует на ней указывать, что у вас там будет Spring Boot версии 3.5.13 и перечислять все контроллеры, которые вы планируете написать. Это излишний уровень детализации.
Наоборот, не надо на Code диаграмме, писать про то, что должен быть процессор — Intel или AMD, оперативной памяти нужно не меньше 16 Гб, а СУБД — Oracle 21. Скорее всего, разными диаграммами будут пользоваться разные люди: программисты, системные администраторы, руководители проектов, аналитики и так далее. Для каждого из них нужны разные уровни детализации и разные пользователи.
При этом возможность перехода между разными уровнями детализации, как мне кажется, это одна из самых сильных сторон C4 модели — не нужно тащить всю информацию с самого верха на нижний слой и наоборот.
Сама концепция модели предполагает, что при необходимости, можно увеличивать и уменьшать «масштаб», переходя на другой уровень модели. Как мы делаем жест пинч (pinch) в картах на мобильных устройствах.
Переходя к практическим аспектам, в первую очередь нужно понимать, в чём модель С4 не особо сильна:
- Описание динамики и потоков. Скорее всего обычные диаграммы последовательности или активности будут более наглядными.
- Бизнес-процессы и бизнес-кейсы.
- Подробное описание диаграмм классов и ER-диаграмм. Их можно использовать на последнем уровне Code, но основной акцент делается на первых трёх уровнях.
Теперь про небольшие моменты, которые упоминаются в документации, но них хотелось бы остановиться дополнительно и их упускают в других обзорных статьях.
Цвет не так важен, как в ArchiMate, но его удобно использовать для группировки или выделения. Например, можно серым цветом обозначить внешние системы, а красным — важные.
Размер. Для людей размер важен, а с диаграммами работают люди (в том числе), поэтому игнорировать размер элементов нельзя. Если нарисовать большой прямоугольник с надписью Nginx, а рядом, небольшой, в котором будет написано Spring Boot, то контейнер большего размера будет восприниматься важнее, сложнее и тяжелее, хотя на самом деле, может быть всё наоборот. Поэтому автор даёт рекомендацию — все элементы рисовать приблизительно одинакового размера, чтобы не создавать искажённое восприятие.
Нотация. Важно не путаться в обозначениях. Их немного, но люди всё равно путаются. Контейнеры — то, что можно развернуть (деплоить), компоненты — нет, они являются частью контейнера.
Например, Nginx — контейнер, SpringBoot Application — контейнер, а вот какой-нибудь FooController или специальный jar-файл, который отвечает за работу с внешней системой — уже компонент. Компоненты мы не устанавливаем отдельно, они поставляются вместе со всем приложением.
Почему в интернете возникают примеры, с перепутанными обозначениями?
Часто так бывает, что диаграммы рисуют не программисты или архитекторы, а аналитики. В лучше случае они рисуют диаграммы после того, как система создана и могут не обладать конкретными техническими знаниями, различать уровни абстракций, просто рисуя диаграммы «со слов» программистов, системных администраторов и руководителей проектов, которые, в свою очередь, не особо знакомы с терминологией и базовыми обозначениями.
Например, под контейнером — программист, DevOps инженер и руководитель проектов может подразумевать абсолютно разные вещи.
Поэтому по-хорошему нужно, во-первых, чтобы все пользователи диаграмм немножко ознакомились с основными обозначениями. Во-вторых, желательно, чтобы на проекте был хоть какой-то архитектор, владеющей нотацией и который мог бы объяснить разным людям в доступной для них форме, что подразумевается под тем или иным элементом на диаграмме.
Ведь на самом деле, можно избежать многих проблем, если вначале подумать, спроектировать архитектуру, по которой уже можно сформировать единый план действий, понятный всем членам команды, а потом уже начинать что-то делать. В таком случае у всех участников будет плюс-минус одинаковое понимание того, что и как нужно делать.
Важно понимать, что архитектура хоть и медленно, но может меняться. Поэтому нужно использовать инструменты, которыми можно пользоваться продолжительное время и вносить корректировки.
В качестве инструментов также предоставлена свобода выбора. Можно даже нарисовать маркером на доске, а потом сфотографировать, что часто является самым быстрым вариантом. Также есть различные онлайн и оффлайн-инструменты, кратко расскажу о тех, с которыми сталкивался.
Инструменты
В крупных компаниях часто используют PlantUML. Поэтому логично использовать C4-PlantUML — PlantUML с поддержкой C4 model. Основной плюс в том, что так вы получите человекочитаемый текстовый формат для описания архитектуры, который легко визуализируется и интегрируется в привычные инструменты разработки (тот же gitlab или что-то другое).
PlantUML давно используется во многих компаниях, сейчас он почти как стандарт де-факто и, конечно, про него нужно знать. В целом он рисует более или менее нормально, но без изысков.
Structurizr — инструмент от создателя C4. Если я правильно понял, инструмент уже ушёл в фазу EOL (End of life), нужно куда-то переходить и ситуация неоднозначная, с которой нужно разбираться. Я им никогда толком не пользовался, хотя он довольно активно продвигается создателем языка, при этом концепция «масштабирования» сделана буквально, что вызывает приятный пользовательский опыт. Можно двойным щелчком перейти на следующий уровень диаграммы и это выглядит просто волшебно.
Сам автор не рекомендует использовать какие-то другие инструменты «общего назначения» а-ля Visio, тем не менее множество таких инструментов он приводит на своём сайте.
Опишу те, с которым работал или работаю.
Lucidchart — платный, но красивый. Мне одно время очень нравился, в первую очередь тем, что это универсальный инструмент. В нём есть большое количество различных видов диаграмм. Если не жалко денег на подписку, то вполне рабочий инструмент. Правда, я в нём больше рисовал другие виды диаграмм, но думаю, для C4 он тоже сгодится.
Draw.io. Также пользуюсь очень давно для различных диаграмм. Если честно, он мне нравится больше других, хотя проблем в нём тоже предостаточно. Что нужно знать при работе с ним:
- Если диаграммы сохранить в svg формат, то будет чисто векторный рисунок. Если выбрать в svg + drawio формат, то тогда сохранятся все метаданные и описание диаграммы. В таком формате этот файл можно сохранить не как рисунок, а именно как диаграмму, чтобы потом внести правки или сохранить у себя в репозитории.
- На момент написания статьи каждый элемент имеет фиксированный размер, что раздражает, поскольку создаёт проблемы с размещением текста. Это можно исправить в настройках самого элемента. Как правило, я сразу меняю, потом использую элемент в качестве шаблона.
Draw.io мне нравится простотой и возможностью контроля. В нём дается больше способов управлять визуальной составляющей — можно поменять расположение и направление стрелок, шрифт, стили, цвета, выравнивание. За счёт этого можно расставить небольшие акценты, которые часто бывают очень полезны для понимания архитектуры всей командой. Если описанием архитектуры будут пользоваться люди, а не только искусственный интеллект, то хочется, чтобы это выглядело немного эстетично.
Конечно, в draw.io не будет такого бесшовного перехода от диаграмм одного уровня к диаграммам другого уровня, как в Structurizr, но диаграммы, сделанные в draw.io, на мой взгляд, выглядят красивее и нагляднее.
Поэтому если диаграммы вам нужно показывать заказчику или менеджменту, то, на мой взгляд, лучше использовать draw.io.
Если диаграммы нужны только для внутреннего использования, для технарей, то следует выбирать то, что удобнее — plantuml, drawio или простой рисунок на бумаге.
В любом случае нужно не забывать, что модель С4 это всего лишь один из множества способов описания архитектуры, который в некоторых случаях довольно удобно использовать, а в некоторых нет. Этот инструмент не является «серебряной пулей», которая решит все ваши архитектурные и организационные проблемы и не является универсальным средством, даже если харизматичный автор в лице Саймона Брауна очень увлекательно о нём рассказывает с трибуны и предлагает попробовать использовать.
Всегда нужно помнить, что содержание важнее, чем форма. Красиво нарисованная диаграмма, описывающая плохую архитектуру, не спасёт ситуацию. Это всё равно, что иметь на руках красиво нарисованный чертёж плохо спроектированного устройства. Результат будет плохим в любом случае, и устройство, сделанное по такому чертежу, не начнёт волшебным образом хорошо работать.
Именно поэтому архитектуру системы должен проектировать опытный архитектор, а не аналитик, системный администратор или менеджер по продажам.
Моё итоговое мнение относительно модели C4: познакомиться — однозначно стоит, уметь её понимать — да, желательно научиться, а вот внедрять в регулярное использование в компании и возлагать большие надежды, перестраивать бизнес-процессы — здесь нет простого ответа, всё зависит от множества факторов.