В середине сентября вышла первая статья о нашем инструменте управления архитектурой DocHub. Прошло два месяца и можно подвести промежуточные итоги внедрения. Они оказались неожиданными и интересными.
Структурированные идентификаторы
DocHub работает с манифестами архитектурных объектов. Манифест это YAML или JSON файл. Например, вот так описывается система с кодовым обозначением 01000:
rdwsoft.rabota.systems.01000:
title: АС Работа.ру (01000)
entity: system
type: Целевая, внедрено полностью
technologies:
- PHP
- RabotaX
aspects:
- rdwsoft.rabota.employer.brand
...
- rdwsoft.rabota.crm_voip
links:
- id: rdwsoft.rabota.systems.06001
direction: '-->'
...
- id: rdwsoft.rabota.systems.01014
direction: '<-->'Когда мы начали описывать наши системы, мы быстро поняли, что одноранговые идентификаторы нам не подходят. Дело в том, что уже в коде необходимо считывать, к какому слою представления относится объект, и частью чего он является.
Для решения этой проблемы были введены структурированные идентификаторы. В примере это “rdwsoft.rabota.systems.01000” где:
rdwsoft - юридическое лицо (компания);
rabota - продукт;
systems - системы реализующие продукт;
01000 - код системы в реестре систем.
Пожалуй, описать идею будет проще графически:
Не находите, что это очень похоже на картинки из C4 Model? Действительно, через идентификаторы мы можем описать C4 Model в текстовом виде. Но в отличии от концепции C4, количество слоев в DocHub не ограничено. Это сделано осмысленно.
Дело в том, что C4 не покрывает уровни корпоративной архитектуры. Например, мы являемся частью экосистемы. Продукты нашей компании интегрированы в нее. Чтобы это представить, нам нужно больше слоев:
На изображении явно видны “дыры” на верхних уровнях. Таким образом, при наличии явной схожести концепции с C4 Model, структурированные идентификаторы не реализуют ее в явном виде.
Обозримость архитектуры
Заметным профитом внедрения структурированных идентификаторов стала возможность обозревать архитектуру в виде дерева.
Хорошо видна топология архитектуры. Легко можно определить принадлежность архитектурных объектов доменам.
Контроль консистентности архитектуры
Киллер-фичей, по моему мнению, стала возможность контролировать консистентность описания архитектуры. Посудите сами, структурированные идентификаторы дают четкое понимание иерархии объектов. Если на каком-то уровне иерархии объекты не описаны, это означает только одно - их упустили.
Это же свойство позволяет внятно связывать фактическую реализацию уровня кода с верхними уровнями описания архитектуры.
Появляется возможность автоматически генерировать (различными анализаторами) описание архитектуры на самом низком уровне, а затем, выявляя “дыры”, заполнять их. Поднимаясь с уровня реализации до самого верхнего уровня абстракции.
Эта фича выразилась в подсистеме контроля консистентности DocHub. В режиме реального времени проектировщик получает информацию об обнаруженных проблемах в описании архитектуры. Работа подсистемы выглядит весьма просто:
Кликнув на пункт меню “Проблемы”, проектировщик получает развернутую информацию о них.
Анализ архитектуры как набора данных
Вышеописанные решения привели к концепции - “Архитектура как данные”.
Обладая описанием архитектуры в виде структурированных данных, возникает возможность проводить ее анализ для различных целей. Например:
Анализ архитектуры на достаточность;
Анализ архитектуры на консистентность;
Валидация архитектуры по принятым стандартам;
Связывание объектов DocHub с внешними объектами;
И т.д. и т.п.
Но, пожалуй, стоит выделить очень важный профит:
Появляется возможность ML анализа архитектуры. Открывается перспективы встраивания интеллектуальных ассистентов проектировщика.
Мне кажется, это действительно важно для проектирования сложных ландшафтов. Кто знает, может именно тут проявится известным нам всем образ из Матрицы.
Итого
Конечно, эта статья целиком не описывает наш опыт внедрения. Скорее это просто “заметка на полях”. Я посчитал важным выделить мысль управления архитектурой, как данными, в отдельную статью.
