Приветствую, коллеги. Меня зовут Мстислав, я являюсь руководителем Python практики в Usetech. В этой статье я раскрою нюансы работы с PlantUML и C4 моделью. Вся информация является выжимкой из нашего ежедневного опыта. Также необходимо упомянуть, что на эту тему я проводил воркшоп на TechLeadConf 2022, так что при желании, вы всегда можете найти видео.

Представьте, что вы работаете в команде над крупным проектом какое-то время. Проект прошел начальный этап и уже работает в продакшн среде. Им пользуются люди, даже можно сказать, что им пользуются много людей и они рассчитывают на ваш продукт, он для них важен. С какого-то момента вдруг вами овладевает беспокойство, что что-то не так. Каждый спринт дается тяжело. Новые задачи вызывают проблемы с внедрением, а после релиза вы ловите один инцидент за другим. Каждый день вы со страхом смотрите в свой месенджер, боясь увидеть очередное сообщение с очередной проблемой, которую нужно срочно решать. Запросы к базе начинают тормозить, важная информация теряться, все валится из рук, контроль над ситуацией утекает как песок сквозь пальцы. Вы начинаете плохо спать, начинают снится кошмары о бесконечных сообщениях в очередях вашего брокера, которые воркеры не способны переварить. Вам снятся сервера, на которых заканчивается CPU и память, потому что сервисы безмерно потребляют ресурсы. Утилизация дисков на серверах с СУБД уже давно под 100%, ведь сервисы что-то постоянно с них читают или пишут. Ошибки, задержки, падения. Вы просыпаетесь.

В работе solution архитектора или системного аналитика есть задачи на проектирование интеграции. Иногда заказчик приносит задачу с требованиями на один абзац.

С чего же начать, если перед вами такие минимальные бизнес требования?

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

В этой статье я хочу показать пример применения нотации C4, который вы сможете использовать как ориентир в своей работе, а также инструменты для её создания. В частности, выделяю Structurizr.

Статья полезна для системных аналитиков, архитекторов, разработчиков, менеджеров проектов и тех, кто участвует в создании и принятии решений по организации архитектуры проекта.

Если у вас есть большая система, состоящая из множества микросервисов, то вы наверняка задавались вопросом: «Что сделать, чтобы архитектурная схема всей системы была всегда на 100% актуальной?».

Обычно, в компаниях есть свои практики формирования архитектурных схем и ведения документации, что частично решает поставленный вопрос. Но проблема такова, что часто схемы со временем начинают расходиться с реальностью: новые интеграции добавляются, а старые — уходят, а актуализация схем вручную происходит не всегда своевременно.

Чтобы решить проблему мы автоматизировали отрисовку схем опираясь на метаданные IT-систем. Мы создали отдельный микросервис, который этим занимается и назвали его «Architect». О том как это происходит и как работает Architect я расскажу в этой статье, а также дам несколько советов, которые помогут внедрить то же самое у вас в компании.