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