[Перевод] Диаграммы по модели C4 для каждого, кто хочет описывать архитектуру в виде кода
Модель C4, предложенная Саймоном Брауном, помогает визуализировать архитектуры приложений, предусматривая для этого 4 уровня детализации: Контекст, Контейнер, Компонент и Код. Такое представление легко воспринимается всеми заинтересованными лицами, как с техническим образованием, так и без него.
Но, если вручную вычерчивать схемы, отражающие различные точки зрения для разной аудитории, такая работа может получиться времязатратной и неэффективной.
Именно здесь блестяще проявляют себя подход архитектура как код (AaC) и, в частности, фреймворк C4InterFlow . С их помощью можно динамически сегментировать и фрагментировать модель архитектуры, исходя из области видимости, уровня детализации и типа диаграммы. На основании этих данных автоматически генерируются диаграммы по модели C4, создаваемые по заказу любого, кто в них заинтересован.
При помощи фреймворка C4InterFlow можно без труда создавать различные представления, сделанные с разных точек зрения. Тем самым гарантируется, что каждой целевой аудитории будет подана картина с подходящими для неё областью видимости и уровнем детализации. Благодаря этому удаётся доступно показать архитектуру, так, чтобы картинка осмысленно воспринималась всеми, кто участвует в работе.
Модель C4
Модель C4 – фреймворк для визуализации архитектуры, разработанный Саймоном Брауном – приобрела популярность в кругу разработчиков и архитекторов по (как мне кажется) двум основным причинам:
В ней делается акцент на Архитектуре Большого Предприятия, которая обычно хорошо понятна всем заинтересованным лицам, как технического, так и нетехнического плана — то есть, речь идёт об Архитектуре Приложений. В соответствии с фреймворком подачи контента TOGAF (см. ниже), Архитектура Приложений удобно располагается между Бизнес-Архитектурой и Технологической Архитектурой. Таким образом, концепции из Архитектуры Приложений легко связать как с нетехническими концепциями из области бизнес-архитектуры, так и с техническими концепциями из области технологической архитектуры.
2. Не составляет труда рассказывать разным аудиториям об Архитектуре Приложений, опираясь на 4 уровня детализации (4 C) этой модели:
Контекст (уровень 1) – программные системы и взаимосвязи между ними в пределах Предприятия
Контейнер (уровень 2) - Контейнеры и взаимосвязи между ними в контексте программных систем
Компонент (уровень 3) - Компоненты и взаимосвязи между ними в контексте контейнеров
Код (уровень 4) – классы и взаимосвязи между ними в контексте компонентов
Точки зрения и представления
Во фреймворке TOGAF определяется ряд ключевых концепций, в частности, Заинтересованные лица, Проблемы, Точки зрения и Представления, которые в совокупности могут помочь архитектору эффективно описывать системы для разных аудиторий. Концепции Точек зрения и Представлений, касающиеся Проблем различных Заинтересованных лиц важны и в том случае, когда модель C4 используется в качестве фреймворка для визуализации архитектуры приложений.
При использовании модели C4 я часто держу в уме два измерения, с опорой на которые мне удобно собирать представления, релевантные для конкретного заинтересованного лица — это уровень детализации и область видимости.
Уровни детализации
Уровни детализации в модели C4 определяются чётко. Кроме того, нетрудно определить наиболее вероятную целевую аудиторию, которой мы будем демонстрировать представления различных уровней детализации.
Область видимости
Есть и ещё одно очень важное измерение, которое необходимо учитывать, если вы пользуетесь моделью C4 для эффективного документирования архитектуры приложений. Речь об области видимости.
При определении области видимости для конкретного представления мы, в принципе, решаем, какие систем(ы), контейнер(ы), компонент(ы) и т.д. включить в представление, ориентированное на конкретное заинтересованное лицо. Это решение должно приниматься одновременно с тем, какой уровень детализации для этого представления выбрать, чтобы гарантировать, что схематическое представление получится как полезным, так и внятным.
Если выбрать большую область видимости и низкую детализацию, то, скорее всего, ваша схема получится слишком нагруженной и непонятной. С другой стороны, ваша схема может получиться не очень полезной, если вы изобразите маленькую область видимости с высокой детализацией.
Проблема
Если учитывать область видимости и уровень детализации всякий раз, когда приходится представлять архитектуру приложения разным аудиториям или в разных контекстах (напр., Проект, Инициатива, Программа и т.д.), то неизбежно придётся чертить (или программировать при использовании инструментов из категории «Диаграммы в коде» ) множество диаграмм. Также можете не сомневаться, что в этих схемах вам придётся дублировать одни и те же схемы и их взаимосвязи… Это всего одна из многочисленных проблем, с которыми придётся столкнуться, если мыслить на языке диаграмм. Эта проблема описана в отдельной статье - How Architecture as Code can solve these 9 PROBLEMS with Application Architecture diagrams.
Да, это Архитектура в коде или, точнее, Архитектурная модель в коде. Я глубоко убеждён, что архитекторы и разработчики должны прекратить чертить (или программировать) диаграммы архитектуры приложений, если хотят, чтобы их документация надолго оставалась релевантной и полезной. Почему именно — объяснено в отдельной статье Drawing Application Architecture Diagrams manually is “INSANE”.
Архитектура в коде
В подход «архитектура в коде» заложена достаточно простая идея — попробуйте выражать модель архитектуры в виде кода и на основе этой модели генерируйте диаграммы, соответствующие различным точкам зрения.
Есть ряд проектов, авторы которых пытались сформулировать предметно-ориентированный язык (DSL), на котором можно было бы выражать модель архитектуры, а также предлагали ряд инструментов для генерации диаграмм. Вот несколько примеров:
Придя к выводу, что мне хочется работать с архитектурой приложений, именно моделируя её, а не вычерчивая диаграммы, я стал оценивать имеющиеся в наличии инструменты. К сожалению, вскоре я осознал, что у всех этих инструментов есть общий недостаток: их DSL выстроены на основе концепций, сильно напоминающих аналогичные концепции из «диаграмм в коде», а именно: Структуры (рамки) и “жёсткие” взаимосвязи (линии). Поэтому я считаю, что это не «настоящие» инструменты для моделирования. Подробнее об этом рассказано в статье My journey to C4InterFlow — Open-Source Architecture as Code Framework.
Да, я решил написать мой собственный фреймворк для этой цели и сделать его опенсорсным :)
C4InterFlow — фреймворк для описания архитектуры в коде
Представление о проекте 💡
Преобразовать ландшафт архитектуры приложений, ликвидировав пробел между моделью архитектуры и кодом.
Миссия 🎯
Предоставить полноценный фреймворк для работы с архитектурой приложений, который позволит IT-профессионалам
1. Без труда выражать архитектуру приложений в коде (AaC)
2. При помощи AaC выстраивать бизнес-процессы в виде кода (BPaC)
3. Автоматически генерировать диаграммы, описывающие архитектуру приложения и бизнеса, а также готовить другую документацию на основе AaC и BPaC
4. Интуитивно анализировать архитектуру приложений, выполняя простые запросы к AaC
Если коротко
Я знал, что модель C4 — это не архитектурный фреймворк, а скорее фреймворк для визуализации архитектуры. Поэтому, внимательно изучив абстракции, входящие в модель C4 (т.e., программные системы, контейнеры, компоненты и код) я сравнил их с метамоделями других фреймворков, в частности, ArchiMate и TOGAF. Тогда я осознал, что в модели C4 Model «не хватает» ключевой концепции, которая могла бы приблизить её к фреймворку моделирования архитектуры, а именно, не хватает Интерфейса.
Программная система состоит из одного или более контейнеров (приложений и хранилищ данных), каждый из которых содержит один или более компонентов, которые, в свою очередь, реализуются через один или несколько элементов кода (классов, интерфейсов, объектов, функций, т.д.).
На диаграммах модели C4 отображаются Структуры (т.e., программные системы, контейнеры, компоненты, т.д.) и их Взаимосвязи, но эти взаимосвязи не смогут сформироваться, если Структуры не будут предоставлять чётких Интерфейсов. Если Структуры предоставляют Интерфейсы, то любой заданный Интерфейс может использовать другие Интерфейсы, и именно так формируются отношения между Структурами.
Затем я задумался о том, как именно каждый конкретный Интерфейс обычно использует другие интерфейсы — и осознал, что возможны ситуации, в которых отдельно взятый интерфейс будет использовать множество других интерфейсов в определённом порядке, а иногда даже в условном. Так я нащупал ещё одну «недостающую» концепцию, а именно Поток.
Метамодель
В C4Interflow кроме Интерфейсов и Потоков также вводятся такие концепции как Пространство имён и Бизнес-процесс.
Пространства имён удобны для того, чтобы логически группировать программные системы (напр., по Предметной бизнес-области или Функции).
Бизнес-процессы могут составляться из Действий, выполняемых Акторами, где каждому действию могут присваиваться Потоки, использующие Интерфейсы.
Все эти концепции открывают новые способы определять область видимости, когда приходится решать, что именно включать в Представление, сделанное с конкретной Точки зрения для конкретного Заинтересованного лица.
Типы диаграмм
Как было сказано выше, фреймворк C4InterFlow укомплектован такими инструментами как CLI, при помощи которых можно генерировать Архитектурные диаграммы. Теоретически, можно автоматически генерировать диаграммы любых Типов, описывающие Структуры и их Отношения, но пока C4InterFlow может генерировать C4, C4 статические, C4-последовательные и UML-последовательные диаграммы.
Тип диаграммы – это ещё одно измерение дополнительно к рассмотренным выше уровням детализации и области видимости. Типы могут пригодиться, когда требуется решать, какое Представление нужно создать для конкретной Точки зрения.
При генерации диаграмм с помощью CLI C4InterFlow можно с высокой точностью задать все три измерения, либо не делать этого, чтобы фреймворк сгенерировал диаграммы для всех возможных комбинаций для всех поддерживаемых значений во всех трёх измерениях.
Визуализация
C4InterFlow CLI предоставляет публикующую команду, позволяющую сформировать из всех автоматически сгенерированных диаграмм статический веб-сайт. На нём любой сотрудник вашей организации может воспользоваться навигацией по Архитектурным диаграммам, рассматривая их по всем доступным областям видимости, уровням детализации, типам диаграмм и форматам (в том числе, работать с исходным кодом диаграмм в PlantUML).
А по следующей ссылке можно посмотреть и другие архитектурные веб-сайты для других образцов C4InterFlow, где архитектура выражена в коде.
Предзаказать книгу: "Модель С4. Визуализация программной архитектуры" со скидкой 35% можно на нашем сайте.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.