1С, СППР и Архитектура как код
Сейчас набирает популярность подход «Архитектура как код» (AaC).
Происхождением он обязан практикам devops «Инфраструктура как код» (IaC).
Идея подхода «Архитектура как код» состоит в том, что объекты архитектуры выражаются в виде формализованных структур со связями, что позволяет, создав некоторый язык программирования, управлять модификацией архитектуры программным кодом. Ну и, конечно, зажать архитектуру в некоторый унифицированный формат описания.
В этом контексте происходит переход от визуального описания архитектуры в виде графических схем к формализованной, из которой, в свою очередь, автоматически производится отрисовка графического представления.
Формализация объектов архитектуры производится в виде простого текста в формате YAML, где объект представлен своими именем и реквизитами. Формат YAML позволяет привести проектирование архитектуры к подходам программирования, в т.ч. к контролю версий объектов наподобие git. Формализация объектов архитектуры вместе с их реквизитами позволяет рассматривать (и автоматизировано обрабатывать!) не только функциональные, но и нефункциональные требования.
Сейчас явно выделяются несколько независимых течений в сфере AaC, со своими форматами, языками и графическими движками. Очевидно, в ходе конкурирующего развития, останутся не все. Что-то станет общеуниверсальным стандартом. Или идея AaC заглохнет, либо маргинализуется среди небольшого числе последователей, хотя бы потому, что выгоды от выделения среди программистов кодеров, кодирующих для других кодеров, чтобы они понимали, что им кодировать, не вполне очевидны.
Какую цель преследует формализация архитектуры как кода? Точнее, какую должна преследовать?
Такой целью должна быть возможность автоматической проверки, соответствует ли системная реализация архитектурному замыслу. Для этого необходимо, чтобы нормы AaC, как разновидность языка описания архитектуры (ADL), были интегрированы в жизненный цикл программного обеспечения.
У меня возникла мысль, а можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.
Вообще-то, специалисты признают, что «Архитектура как код» это маркетинговый слоган, теоретически и идеологически правильно называть этот подход «Архитектура как данные», но он, считается, менее понтово звучит. Тем не менее, в этом контексте близость AaC и 1С становится ещё сильнее.
Смотрим внимательно на AaC и видим, что объект+реквизиты это вообще-то стандартные метаданные 1С. По сути, архитектор-кодер даёт имя сущности (объекту) и даёт ему набор реквизитов и их значений. В этом контексте «описать объект архитектуры» означает:
- дать объекту имя;
- определить список его реквизитов;
- заполнить реквизиты значениями;
- определить связи объекта.
Ничего не напоминает?
Да, напоминает, если мы зададим объект как Документ, т.е. метаданное конфигурации 1С. Тогда, создав вид документа в конфигураторе и задав ему реквизиты, мы получаем интерфейс для объекта архитектуры. Переходим в платформу и можем описывать объекты архитектуры документами и заполнять реквизиты документа значениями.
Ну и где тут YAML?
Помним, что конфигурация 1С выгружается в XML-файлы по каждому объекту метаданных?
А что документы платформы могут выгружаться в тот же формат XML со значениями реквизитов?
Ну а YAML считается таким же форматом разметки, как XML, хотя и специально сильно упрощённым. Конвертер YAML/XML не вопрос сделать.
Что мы получаем при таком подходе?
- Язык обработки архитектуры.
- Это язык 1С.
- Хочешь - строй и модифицируй на нём объекты метаданных, хочешь - заполняй и меняй реквизиты объекта, хочешь - строй правила проверки архитектуры, объединяй виды объектов архитектуры в слои/структуры.
- Готовых специалистов по AaC со знанием языка.
- Это язык 1С.
- Готовый функционал управления разработкой архитектуры и кода разработки по аналогии с обычным кодингом для 1С на git-технологиях или в привычном конфигураторе/EDT.
- Возможность многопользовательской разработки архитектуры;
- Хронологические срезы состояния архитектуры как релизы.
- Готовый функционал платформы для обработки архитектуры.
- Версионирование (история данных) – аналог ветвей git для данных;
- Выгрузка прототипов (схем) YAML в виде XML из конфигурации;
- Планы обмена для выгрузки данных архитектуры в другие системы в XML(YAML) или для графической отрисовки;
- Импорт архитектурных описаний и списков универсальных архитектурных объектов/реквизитов из других систем через тот же план обмена;
- Документирование через поля комментариев и/или справку;
- Резервное копирование;
- Механизм ввода на основании, как связь между объектами архитектуры, лежащими в одном горизонтальном слое. В платформе это будет наследование реквизитов с обработкой или без обработки их значений;
- Механизм дополнительных свойств для описания вертикальных связей объектов архитектуры.
- Отчёты для обзора архитектуры и её данных.
- Выгрузка в СППР для увязки требований к архитектуре с её описанием.
- Возможность описания архитектуры не1С-систем в 1С в едином массиве с конфигурациями 1С.
- Ведь для описания архитектуры важно имя сущности, а не что она заключена в стандартный 1С объект метаданных «Документ».
Чего не хватает?
- Не хватает графического описания архитектуры. У 1С с этим бедно. Можно воспользоваться отрисовкой IDEF0 в СППР, ER диаграммой в EDT. Можно попытаться приспособить табличные или графические отчёты. Но, скорее всего, лучшим решением будет выгрузка для отрисовки в DocHub или Archimate или аналогичный продукт/сервис.
- Не хватает функционала по осуществлению главной функции AaC – проверке соответствия архитектуры её исполнению.
Здесь хотелось бы послушать читателей, тут нужен коллективный мозговой штурм
Буду признателен за обратную связь.
Вступайте в нашу телеграмм-группу Инфостарт
