Некоторое время назад у меня возникла необходимость в документировании принимаемых архитектурных решений и в предварительном описании архитектуры на этапе планирования, в рамках технического проекта. Первым делом пробовал для этого приспособить UML, но как-то не пошло. Потом познакомился с таким инструментом как C4Model – нотацией для визуального моделирования программной архитектуры. О ней хотел бы рассказать поподробнее.
Как моделировать архитектуру приложения?
Из существующих на сегодняшний день средств для визуализации архитектуры программного обеспечения можно выделить UML и ArchiMate. Если вы знаете ещё какие-нибудь классные альтернативы, то напишите, пожалуйста, о них в комментарии. Помимо перечисленных, также существует такое решение как “Box & Arrows“, в котором мы используем прямоугольники для представления сущностей и стрелки для указания связей между ними.
Данные средства и подходы, которые формируются под их влиянием, обладают рядом недостатков. В первую очередь, нужно знать “синтаксис” указанных средств моделирования, например, в UML используется несколько различных типов линий с разными видами указателей на концах, и каждый из этих вариантов обладает своей специфической семантикой. Проблема усугубляется тем, что с архитектурными моделями работают не только разработчики, но и представители заказчика. С учетом того, что не все разработчики знакомы с нотацией UML, ждать, что люди из бизнеса будут с легкостью читать такие модели было бы опрометчиво. Помимо этого UML сам по себе не провоцирует нас к тому, чтобы мы создавали модели на разных уровнях абстракции. Более того, в рамках одной модели можно случайно смешать довольно низкоуровневые и высокоуровневые вещи.
Если вернуться к варианту “Box & Arrows“, то при использовании этого подхода высока вероятность, что люди, не знающие контекста, в рамках которых обсуждалась архитектура, вообще не поймут о чем идет речь, а те кто участвовал через пару месяцев могут просто забыть ряд ключевых для понимания вещей. Т.к. в “Box & Arrows” нет заранее известной семантики, она фактически, создается во время обсуждения.
Альтернативой перечисленным подходам является модель C4 для визуализации программной архитектуры.
В чем идея C4Model?
Основная идея модели C4 заключается в том, что она предоставляет своего рода карту (в классическом ее понимании) для программной системы. Причем карта с возможностью масштабирования.
При работе с картой, когда нам на ней что-то нужно найти, мы, вначале, выставляем очень маленький масштаб (уровня страны или мира), далее, увеличиваем до интересующего нас региона, потом города и уже потом улицы/дома, который мы ищем.
Модель C4 предлагает похожий подход: четыре диаграммы, каждая из которых отвечает за свой уровень масштаба (детализации) проектируемой системы. При этом количество абстракций, которыми нужно оперировать минимально, это позволяет работать с диаграммами тем, кто не является специалистом в области разработки программного обеспечения.
На самом высоком уровне располагается диаграмма контекста. Это первая диаграмма, с которой начинают проектирование системы, или знакомство с ней, если она уже спроектирована в этой нотации. На уровне диаграммы контекстов представляется то, как наша система взаимодействует с внешним миром.
Далее следует диаграмма контейнеров – это второй уровень масштаба системы. Переходя на него, мы на один шаг спускаемся вглубь детализации нашей системы. Контейнеры, в данном случае, это не контейнеры в понимании единцы развертывания систем (типа Docker-контейнеров), это крупные строительные блоки нашей системы: веб-серверы, серверы-приложений, базы данных, мобильные приложения и т.п. Если система разворачивается на одном сервере, то контейнеры можно воспринимать как отдельно запущенные процессы.
Первые два вида диаграмм могут быть частью технического проекта, который обсуждается архитектором совместно с аналитиками и представителями бизнеса. Как уже было сказано выше, эти диаграммы очень просты для понимания и не требуют каких-то глубоких технических значений для того, чтобы их читать и обсуждать.
Следующие два уровня больше про технические особенности системы. Их уже архитектор обсуждает с командой, которая будет заниматься реализацией проекта.
Третий уровень – это диаграмма компонентов. На ней отображается структура контейнеров, которые были выделены на уровне выше. Причем не обязательно всё делать на одной диаграмме. Можно их сделать несколько, так чтобы каждая раскрывала детали каждого контейнера индивидуально. Это позволит держать в голове все необходимы аспекты, касающиеся элементов системы, не позволяя излишней сложности снизить уровень понимания работы системы.
Четвертый уровень не всегда используются при работе по модели C4. Это диаграмма кода, на ней в виде UML (или подобной нотации) описываются важные, с точки зрения разработки/проектирования, аспекты системы.
Рассмотрим более подробно основные абстракции модели C4, а также содержимое и правила построения диаграмм Контекста, Контейнеров, Компонент и Кода.
Основные абстракции в C4Model
Абстракции, которые предлагает использовать модель C4, являются основными структурными элементами системы, которыми, как правило, пользуются архитекторы и проектировщики при формировании дизайна системы.
На самом верхнем уровне располагается проектируемая Программная система, она в свою очередь состоит из набора Контейнеров (приложения и хранилища данных). Каждый контейнер состоит из Компонент, которые разработчики имплементируют в виде кода. Помимо структурных элементов системы существуют также пользователи, взаимодействующие с нашей системой.
Таким образом мы имеем следующий набор абстракций.
Пользователи
Условное обозначение:
Определяют людей, которые будут пользоваться нашей системой.
Для связи элементов диаграммы между собой используется штриховая линия с надписью.
Программная система
Условное обозначение:
Элемент, который определяет разрабатываемое нами решение, как некоторый один неделимый блок.
Контейнер
Условное обозначение:
Это приложение или хранилище данных. Контейнер – это то, что запускается обособленно от других элементов общей программной системы. Например: веб-сервер, сервер приложений, база данных, очередь (Kafka и т.п.), файловая система, мобильное приложение, single-page application и т.п.
Компонент
Условное обозначение:
Компоненты – это то из чего состоят контейнеры (наборы классов, отдельные пакеты (jar-, dll-библиотеки) и т.п.). В рамках идеологии модели C4, компоненты – это такие структурные элементы, которые не разворачиваются и не запускаются в виде отдельных сущностей.
Виды диаграмм в C4Model
Рассмотрим более подробно особенности диаграмм модели C4.
Диаграмма Контекста
Диаграмма контекста представляет собой наиболее абстрактный вид системы. Она показывает положение разрабатываемой программной системы относительно других систем, а также представляет пользователей системы и тех, кто с ней взаимодействует.
Эта диаграмма может использоваться как техническими, так и не техническими специалистами.
В рамках данной диаграммы используются следующие абстракции:
Диаграмма Контейнеров
Это следующая, после диаграммы контекста, по уровню детальности схема. На Диаграмме Контейнеров отображается совокупность контейнеров в понимании модели C4, из которых состоит разрабатываемая система. При этом, на диаграмме могут располагаться внешние системы, они представляются в виде серых прямоугольников, без детального описания структуры.
Контейнеры – это отдельно развертываемые приложения: веб-серверы, серверы приложений, web-приложения и т.п. То есть что-то такое, что можно брать и запускать отдельно от остальных частей системы.
На этом уровне чаще всего используются следующие элементы:
Работая с диаграммой контейнеров мы продолжаем находиться на уровне всей системы. Основные элементы, на которых должно быть сконцентрировано наше внимание – это контейнеры, второстепенные элементы – это пользователи и внешние (по отношению к нашей) сторонние системы, с которыми разрабатываемая система каким-то образом взаимодействует.
С этим типом диаграмм могут работать представители бизнеса, архитекторы и техническая команда.
Диаграмма Компонент
На Диаграмме Компонент представляется внутренняя структура компонента. Часть контейнеров системы может браться уже готовыми, например, база данных, её внутренне устройство не нужно представлять на этой диаграмме. Но некоторые контейнеры необходимо разработать в рамках создания программной системы. Вот их устройство и нужно будет представить.
На Диаграмме Компонент детально представляется какой-то конкретный контейнер в виде совокупности связанных компонент. Оставшиеся контейнеры представляются целиком (без детализации), дополнительно могут быть представлены внешние системы, с которыми взаимодействуют компоненты контейнера.
Как правило, в рамках данной диаграммы используют следующий набор абстракций:
Диаграмма Кода
Четвертый, финальный, уровень модели C4 – Диаграмма Кода. Основными компонентами этой диаграммы являются элементы реализации компонента: классы, интерфейсы, функции и т.п. Чаще всего на этом уровне можно встретить диаграммы UML, описывающие структурные и поведенческие аспекты разрабатываемых элементов системы.
С диаграммами этого уровня работают только архитекторы и разработчики, представители бизнеса уже не участвуют в обсуждении возникающих здесь вопросов.
Пример. Сервис отправки постов в Telegram-каналы TelegramPosting
Рассмотрим, как могут выглядеть диаграммы модели C4, на примере проектирования сервиса для автоматизации публикации сообщений в Telegram-каналы.
Для начала построим диаграмму Контекста, на ней весь наш сервис представляется в виде одного прямоугольника.
С нашим сервисом (TelegramPoster), работают два типа пользователей – это администраторы, которые добавляют каналы в систему и настраивают их (доступ и регламент рассылки), и пользователи системы, они добавляют через специальный интерфейс посты для публикации в канал.
На следующем уровне располагается диаграмма Контейнеров. На ней мы более детально представляем внутреннее устройство системы постинга сообщений. Контейнеры, как мы помним – это независимо развертываемые единицы, они все могут располагаться как на одном сервере (запускаются как отдельные исполняемые файлы), так и в отдельных docker-контейнерах. В дополнение к представленным на рисунке контейнерам, можно предусмотреть наличие реверсивного прокси, на базе IIS/Nginx/Apache/YARP.
Далее, наша задача – это рассмотреть подробно структуру контейнеров на диаграмме Компонент. Мы это сделаем только для одного – Web API App. Для Web API App пользователем является Single-Page App, именно он отправляет в него запросы по REST API согласно нашей задумке.
Внутри контейнера выделим следующие компоненты:
- SignIn Controller – контроллер, предоставляющий API для регистрации и настройки пользователей.
- Security Component – application service, решающий задачу регистрации и настройки пользователей.
- TelegramChannels Controller – контроллер, предоставляющий API для создания и настройки Telegram-каналов.
- TelegramChannels Component – application service, решающий задачу создания и настройки Telegram-каналов.
- TelegramPoster Controller – контроллер, предоставляющий API для работы с пулом постов для Telegram-каналов.
- TelegramPoster Configuration Component – application service, работающий с пулом постов для Telegram-каналов.
- TelegramPoster Component – hosted service, который по заданному регламенту для каждого Telegram-каналов делает отправку постов из пула.
Что ещё почитать на эту тему?
Наиболее подробная информация по модели C4 представлена на официальном сайте этой методологии https://c4model.com/.
Помимо теоретического материала, вы там можете найти информацию о том, как представлять C4 диаграммы используя UML и ArchiMate, часто задаваемые вопросы и довольно удобный визуальный инструмент для подбора средства создания C4-диаграмм по ряду ключей.
