hexagon
📙 Hexagon entry article (readme.md)
Hexagon
Hexagon – это функциональное расширение для создания метамоделей и описания архитектуры в DocHub без использования jsonata. В SEAF 1.0 слой Бизнес-архитектуры реализован с помощью Hexagon
Для описания архитектуры в виде кода в Hexagon используетсятся ограниченный набор yaml-конструкций, образующих hex-native язык:
- декларирование объектов и отношений в формате направленного графа, где объекты представлены вершинами (узлами, nodes), а отношения -- ребрами (связями, edges);
- запросы (queries) к графу следующего вида: все ноды, которые имеют связь (любую или определенную) с нодами, которые имеют связь... Не путать с jsonata-запросами.
- описание представлений архитектуры в виде pattern(комбинация запросов) + landscape(результат комбинации запросов)
- интерпретация кода архитектуры, написанного в других схемах (TBD)
Декларирование объектов и отношений
Все объекты архитектуры с точки зрения Hexagon являются однотипными или True Typeless (hex.ttl). То есть и объект "Медиа-платформа", и объект "Центр" будут относиться к типу hex.ttl. Поэтому декларирование этих объектов будет выглядеть следующим образом:
hex.ttl: # раздел манифеста, в котором объявляются любые объекты архитектуры sber.berezka.media_platform_self: # уникальный идентификатор объекта (рекомендуем использовать концепцию DDD) title: Медиа-платформа # наименование наименование объекта
sber.center: title: Центр
Если между парой объектов архитектуры существует отношение, например "'Центр' владелец 'Оплаты онлайн' ", то объявляение такого отношения осуществляется следующим образом:
hex.ttl:
sber.center: title: Центр hex: sber.center.aquiring: # объект-источник (source) связи title: Оплата онлайн hex: # атрибут объекта в котором объявляются связи =>владелец: # направление и наименование связи sber.center: # объект-приемник (target) связи
На данном этапе ни DH, ни Hexagon ничего "не знают" о природе декларируемых объектов. Это два каких-то связанных объекта. Для того, что бы в дальнейшем оперировать такими категориями как "Участник"(экосистемы) и "Продукт", их необходимо задекларировать, как и "обычные" объекты:
hex.ttl: mm.party: title: Участник
mm.product: title: Продукт
Для того, чтобы "Центр" и "Эквайринг" относились к категории (классу, признаку и т.д.) "Участник" и "Продукт" соответственно, необходимо задеклариировать отношения между классами и экземплярами. В примере ниже используется отношение
, но можно выбрать любое отношение:
hex.ttl: sber.center: title: Центр hex: =>map: # мэппинг Центра mm.party: # на класс Участник
sber.center.aquiring: title: Оплата онлайн hex: =>map: # мэппинг Эквайринга mm.product: # на класс Продукт =>владелец: sber.center:
Подключите пример "Березка" и в папке ba сможете увидеть болльше примеров
Для получения перечня всех объектов и отношений можно воспользоваться jsonata-запросами:
$eval($$.hexF.nodes) /* все объекты */
$eval($$.hexF.edges) /* все отношения */
подробнее о декларировании объектов и отношений
Запросы к графу
Запрос - это специальный атрибут
hex.ttl-объекта, описывающий условия по наличию/отсутствию отношений с другими объектами. Запросы возвращают массив идентификаторов объектов архитектуры, удовлетворяющих заданным условиям.
Например, требуется получить перечень всех Участников:
hex.ttl: all_parties: # идентификатор запроса title: все Участники # имя запроса hexQ: # атрибут, содержащий запрос hex.ttl: # все hex.ttl-объекты, которые EVERY=>map: # в обязательном порядке имеют исходящую связь "map" mm.party: # к объекту mm.party
Выполнить запрос можно с помощью jsonata:
$eval($$.hexF.queryExe, {"qId": "all_parties"})
Поскольку запрос - это hex.ttl-объект, то мы можем поместить тело запроса, например в объект mm.party:
hex.ttl: mm.party: title: Участник hexQ: hex.ttl: EVERY=>map: mm.party:
Теперь при обращении mm.party является и обычным hex.ttl-объектом и запросом одновременно:
( $lookup(hex.ttl, "mm.party").title; /* Участник */ eval($$.hexF.queryExe, {"qId": "terminal"}); /* [ "sber.center", "sber.berezka", "fl", ... ] */)
Визуализация (views)
Визуализация определенной части графа называется "view" (вью, представление). В Hexagon представления описываютяся (декларируются) кодом и строятся следующим образом:
- hex.ttl-объект, содержащий в себе определение view -- заголовок, описание, статья выводятся в верхней части view
- декларируемая часть (определение) -- представляет собой pattern (что показывает view) и отображается в виде графа с селекторами
- вычисляемая часть -- результат применения паттерна к графу -- подграф, соответствующий паттерну.
Рассмотрим пример:
hex.ttl: ecosystem: title: Экосистема hexV: modes: # данный вью содержит в себе subview # - title: Предложения экосистемы # hexV: # # mm.parties_interested.hexQ: # # mm.products_targeted.hexQ: # mm.parties_providers.hexQ:
- title: Использование продуктов # наименование subview hexV: # pattern, состоящий из mm.party.hexQ: # запроса mm.party и mm.product.hexQ: # запроса mm.product и # всех связей между hex.ttl-объектом mm.party и hex.ttl-объектом mm.product (по умолчанию) hexR: # параметры рендеринга nest: # вложить - <=используется в: # объекты источники в объекты-приемники
hexNav: # Добавление презентаций DH в меню, в частности, - title: SEAF Business Architecture (Hexagon) # в раздел "Hexagon/SEAF Business Architecture (Hexagon)" добавить link: params: includes: - title: Экосистема # пункт "Экосистема" вью", ведущий к link: "entities/hexV/view?id=ecosystem" # презентвции view of entity hexV и параметром id=ecosystem
Описание
Расширение для создания метамоделей и описания архитектуры в DocHub без использования jsonata
Языки
CODEOWNERS