В статье предложен радиально-кольцевой метод проектирования архитектуры области (в частности - интеграционной схемы), состоящей из нескольких информационных систем, проведены общая оценка применимости этого варианта в различных ситуациях и его сравнение с классическим «макаронным» представлением. Взгляд сугубо субъективный и прикладной. Если вдруг статья привлечет очень много профессионалов – прошу придерживаться культурных о(б)суждений 😊
Как всё началось
Началось все очень просто – в норе под землей с постановки прикладной задачи, а именно: требуется разработать интеграционную схему области, состоящей из 10 информационных систем (ИС), при этом:
1. Необходимо:
отразить все интеграционные связи каждой из 10 ИС (интеграции возможны как с ИС области, так и с ИС смежных областей (их 8));
понимать содержание интеграционных потоков.
2. Желательно:
понимать все вышеперечисленное быстро;
иметь возможность масштабировать архитектуру.
Примечание: предлагаю не демагогить по поводу понятий «область», «ИС», «архитектура», «интеграция» и прочее, сведем все к базе – есть объекты и связи между ними, по которым течет какая-то данная, которую надо понимать. Вот это все безобразие и надо показать.
Еще немножко истории - и перейдем к сути.
Первое, что пришло мне на ум – пойти стандартным путем: нарисовать квадратиков и начать рисовать между ними стрелочки с подписями. Вроде того, как представлено на рисунке:
Так я и сделал (10 ИС области + 8 ИС смежных областей = 18 действующих лиц), однако очень скоро я уткнулся в проблему топологии – где-то после 25 стрелочек рисовать их стало некомфортно, при этом интеграции требовалось отразить на уровне атрибутов, а не смысловых потоков данных.
Я сел и начал думать на тему универсальности, и, кажется, что-то получилось… Получился радиально-кольцевой метод (далее – РКМ) проектирования архитектуры .
Итак - РКМ
Метод реализует представление архитектуры в радиально-кольцевой структуре, где радиально направлены потоки данных, а кольца (контура) играют роль шины (на схеме залита зеленым).
При этом сами ИС делятся на 2 типа:
ИС области;
ИС смежных областей.
База под наши исходные данные такая:
В качестве инструмента отсюда и далее я использовал confluence (draw.io). Как видите, каждой ИС я также присвоил свой цвет. Решение не совсем масштабируемое (цвета так-то не бесконечные, знаете ли) и совершенно не обязательное, но в рамках моей задачи было весьма неплохое.
Главная особенность данного представления — возможность «убирать» линии связей (потоки данных) в контур интеграций, благодаря чему значительно экономится место и упрощается поиск и понимание связей, относящихся к конкретной ИС. То есть поток может в любом месте войти в контур и из любого места выйти.
В нашем случае схема с нанесенными связями выглядит так (исходные данные абсолютно реальные):
Как видите, на схеме появились стрелочки с надписями, поэтому пришла пора заявить о правилах.
Правила
Первое, что необходимо для любой успешной работы в целом — это задать правила. Поехали.
Правило №1 – «Названия». Каждый поток данных должен иметь уникальное название/номер. При разработке РКМ я формировал названия так «первая буква системы – порядковый номер потока», пример – «В-1». При этом название потока дается по системе-потребителю (в случае, если источник – ИС области) или по системе-источнику (если потребитель – ИС смежной области).
Правило №2 – «Без таблиц – никуда». Каждому поток соответствует описательная таблица. При разработке РКМ применялась таблица вида:
Правило №3 – В рамках связи «система - система» может быть максимум два интеграционных потока, они разнонаправлены. В случае необходимости добавления нового атрибута в интеграцию — просто изменяем соответствующую таблицу соответствующего потока.
На самом деле дальше перечислять не буду, так как правила – результат договоренностей в каждой конкретной ситуации, я просто хотел показать, что они всегда нужны и всегда важны! И да, вы правильно заметили, что правила я привел универсальные, что для РКМ, что для макаронного метода (далее - ММ).
Для сравнения — вот схема, нарисованная ММ со всеми теми же связями, что я приводил на схеме выше для РКМ:
Отмечу, что при отрисовке макаронной схемы я не халтурил, а прямо сел и потратил время для чистоты эксперимента, старался то бишь 😊 Сразу прошу меня простить – названия потоков не нанес.
В целом обе схемы выглядят вполне нормально, читаемо, не перегружено.
Эксперимент
Теперь попробуем проверить каждую из них на масштабируемость. Добавим одну новую ИС (ИС-Х, выделена красным), на которую навесим 4 двусторонних связи «система-система» и еще 8 произвольных связей «система-система», которые навесим на старые системы.
Вот так будет выглядеть архитектурная схема, нарисованная по РКМ:
А вот так будет выглядеть схема, нарисованная по ММ:
Как видите, «макаронная» схема стала выглядеть значительно нагруженней, в том время, как схема, нарисованная по РКМ, не сильно изменила своего внешнего вида.
Выводы (напоминаю, субъективные)
Оформлю выводы в виде таблички сравнения двух методов. Что хуже, что лучше в абсолюте — решать вам.
| РКМ | ММ |
Применимость (субъективно) | Много ИС и у них много связей с окружением | Одна ИС и нужно отразить только ее связи с окружением |
Масштабируемость | Бесконечная, за счет наращивания контуров и количества ИС | Ограниченная, в какой-то момент станет невозможно читать |
Сложность чтения | Придется научиться читать, создать минимальную систему правил | Легко и привычно читать даже без правил, но правила никогда не помешают ;) |
Скорость добавление новых интеграций | Одинаковая (небольшая) при любом количестве ИС | Возрастает с увеличением количества ИС и связей |
Устойчивость к изменениям | Максимальная, не зависит от количества ИС и их относительного расположения на схеме | Сложность изменений растет с увеличением количества ИС и связей, относительное расположение важно учитывать |
Информативность (количество информации на единицу площади) | Максимальная, вокруг одной ИС сосредоточены все интеграции, в которых она участвует | Меньше, чем при использовании РКМ. Нужно «ходить» по стрелочкам. |
Ищите удобное вам, совершенствуйтесь, и да прибудет с вами kaizen!