Введение
Модель 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), на котором можно было бы выражать модель архитектуры, а также предлагали ряд инструментов для генерации диаграмм. Вот несколько примеров:
Structurizr
Archinsight
FINOS Labs Common Architecture Language Model (CALM)
https://github.com/dwmkerr/architecture-as-code
https://github.com/jsoconno/architectures
Придя к выводу, что мне хочется работать с архитектурой приложений, именно моделируя её, а не вычерчивая диаграммы, я стал оценивать имеющиеся в наличии инструменты. К сожалению, вскоре я осознал, что у всех этих инструментов есть общий недостаток: их DSL выстроены на основе концепций, сильно напоминающих аналогичные концепции из «диаграмм в коде», а именно: Структуры (рамки) и “жёсткие” взаимосвязи (линии). Поэтому я считаю, что это не «настоящие» инструменты для моделирования. Подробнее об этом рассказано в статье My journey to C4InterFlow — Open-Source Architecture as Code Framework.
Да, я решил написать мой собственный фреймворк для этой цели и сделать его опенсорсным :)
C4InterFlow — фреймворк для описания архитектуры в коде
Представление о проекте
Интересные статьи
Интересные статьи
