Diagrams as code 2.5

Подход “Диаграммы как код” набирает все большую и большую популярность. Простая идея – создавать и редактировать описания диаграмм на некотором формально языке, а потом визуализировать их автоматически – завораживает. Идея не сильно новая. Первое упоминание о программа Graphviz, рисующей картинки, описанные на языке DOT, датируется 1991 годом. Вслед за ней появилось еще много чего. От горячо любимого всеми PlantUML до явно недооцененного сервиса Ilograph

Автор С4 model Simon Brown озвучил даже концепцию Diagrams as code 2.0 , рекомендующую описывать в виде кода единую архитектурную модель решения. Чтоб получить из такой модели картинку нам предстоит совершить операцию, похожую на применение ccs-стиля к веб-странице. Во-первых, мы определяем какие элементы модели должны попасть на диаграмму. Во-вторых, преобразуем элементы архитектурной модели, в инструкции понятные программе визуализации. Тому же PlantUML, например. Подробнее идею Саймона можно посмотреть по ссылке выше. Безусловно она, не столько про упрощение визуализации, сколько про разделение моделей и диаграмм. Это один из ключевых трендов современной ИТ-архитектуры, который точно не следует игнорировать.

Но написать этот короткий пост я хочу несколько о других вещах. Подход Диаграммы как код, не важно какой версии – замечателен. Он будет развиваться своим чередом. Возможно, что однажды мы придем к единому текстовому языку описания диаграмм, как это случилось с картинками и UML. Возможно нет. Меня волнует другое. Чем глубже мы погружаемся в задачу автоматизации рисования картинок, тем меньше задумываемся над вопросами: кто, зачем и как будет наши диаграммы использовать. Вопросы эти для архитектора не очень приятные. Доля рисунков, ненужных вообще никому ненулевая. Потому и отвечать на такие вопросы не очень хочется. Но игнорировать их тоже нельзя. Просто потому, что иначе мы не поймем, что и как на этих диаграммах следует отображать.

Но здесь мы сталкиваемся с рядом сложностей, о которых я и собираюсь поговорить. Первая из них в том, что отображать на диаграмме мы можем довольно разные вещи:

1. Факты, т.е. истории о том, что в состав нашего решения входит 35 независимых сервисов. Описание 5-7 сервисов мы нормально восприняли бы из текста или таблички. Но табличку на 35 строк поместить на страницу проблематично и потому простая кластерная диаграмма здесь будет вполне уместна. Можно заодно и какие-то дополнительные атрибуты, например runtime environment, указать. Или в группы эти сервисы собрать на основании тех или иных признаков. Чего не стоит делать, так добавлять на такую диаграмму взаимодействия между этими сервисами
2. Другая ситуация с рисованием диаграмм TO-BE, описывающим не факты, а наши договоренности о будущем. Возможно, еще даже не договоренности, а предложения. Здесь 35 договоренностей за раз все равно никто не воспримет. Потому и рисовать их бессмысленно. Ну, разве что мы хотим сообщить коллегами, что к набору из 35 сервисов добавляем еще парочку. Тогда он еще как-то будут уместны в дополнении к картинке из предыдущего пункта. Но главным для восприятия здесь является разница между AS-IS и TO-BE, а не неизменная часть, остающаяся в фоне
3. И совсем другая история – концепции, которыми мы хотим поделиться. Здесь как с паттернами проектирования, важно не то что вы думаете, рисуете или пишете, а то, что по завершению разговора будет думать ваш собеседник. Если говорить про картинки, то это скорее многошаговые анимации, в которых один процесс пытается обратится к объекту, заблокированному другим процессом, получает ошибку и возобновляет попытки через некоторое время.

Из всех этих групп ситуаций диаграммы-как-код могут быть полезны скорее в первой. Когда сами факты мы можем извлечь из некоторых описаний или непосредственно из нашей боевой среды, атрибутировать их статическими или изменяемыми показателями и визуализировать в виде картинок. По сути, мы говорим о создании специфически дашбордов. Наверное, здесь все больше и больше будет появляться готовых решений, которые будут отрисовывать объекты, их свойства и отношения автоматически. Со временем авторы таких инструментов сделают картинки понятными для человека.

Но мне, как архитектору, интересней два других случая. И здесь мы скорее будем говорить о поведении, т.е. визуализировать захотим череду событий, каждое из которых связывает некоторые объекты данных, компоненты решения, интерфейсы, через которые происходят взаимодействия и условия, выполнение которых позволяет событию состоятся. Непростая выйдет картинка. Но идея визуализировать связные вещи в разных представлениях и так слишком долго мешала полноте выражения наших мыслей. Вряд ли мы захотим сейчас, например, набор состояний объекта представлять одной диаграммой, команды, служащие для переходов из одного состояния в другое, на следующий, а действующее лицо, их посылающее на третьей. Такие общие диаграммы можно придумывать, пусть это и не очень просто.

Существенную пользу может нам оказать идея Якобсена-Коберна о выделении в сложном графе поведения системы основного сценария – линейной последовательности шагов, приводящих инициатора сценария к его цели. Все остальные варианты развития событий оформляются как обработчики исключений, происходящих в ходе выполнения основного сценария. Практически это канбан-доска, стикеры с которой иногда могут срываться на обработки в другие доски. Такой подход позволяет использовать для визуализации сценариев привычные диаграммы последовательность. Правда мне кажется, что это только начальная точка при рисовании хорошей диаграммы. Часто нам интересно посмотреть сценарии, развивающиеся одновременно, их зависимости через общие компоненты или данные и прочие похожие вещи.

Мне кажется, что ценность текущих нотаций моделирования преувеличивается, а ценность экспериментов в визуализации архитектурных моделей недооценивается. Актуальной задачей будет оставаться, как побудить людей работать с архитектурными диаграммами, получая от этого пользу, а вовсе не технологии, позволяющие нагенерить большой объем диаграмм в единицы времени