Transcription
Привет! Это канал lon it, и сегодня мы слушаем статью "Как описать большую систему в нотации C4" от автора Дима Фролов. Который написал эту статью на сайте hi.com. Спасибо автору за статью, и ссылочка на статью, конечно, будет в описании к этому видео. Мы сейчас расскажем, как моделировать и описывать архитектуру. Но начать я бы хотел с того, где эту архитектуру расположить. Особенно острый вопрос недорогой инфраструктуры встаёт у начинающих проектов. И если смотреть в сторону надёжных, бюджетных вариантов, то стоит рассмотреть специальное предложение от Cloud.ru - Evolution Free Tier. Cloud.ru - это провайдер облачных и AI технологий. Команда насчитывает более 1.400 профессионалов в области IT, AI и кибербезопасности. Ребята делают задачи клиентов любого масштаба и делают доступ к технологиям простым и удобным. Evolution Free Tier - это объём облачных ресурсов, за которые не нужно платить. То есть, если хочешь запустить своё приложение, бота, или, например, поднять VPN шлюз, без проблем. Регистрируешься в личном кабинете cloud.ru, в несколько кликов бесплатно разворачивает виртуальную машину и сразу можешь использовать её для своего проекта. И да, срок действия виртуалки не ограничен, она твоя навсегда. Также в подарок дают объектное хранилище S3 на 5 Гб для загрузки данных любого типа. Единственное, для виртуалки понадобится публичный IP. Его можно будет либо самостоятельно оплатить за 146 руб., либо воспользоваться бонусами. Cloud.ru каждому новому пользователю даёт 4.000 бонусов при привязке карты или регистрации через Сбер ID. Один бонус - это 1 рубль. Так что бонусами можно сразу и IP-шник оплатить. Если интересно, переходи по ссылочке в описании, регистрируйся и разворачивай виртуальную машину бесплатно в пару кликов.
Ну а мы возвращаемся к нашей диаграмме C4. На самом деле, на Хабре статья опубликована под пользователем Дима Фролов, но по факту авторами являются два человека: Дмитрий Фролов и Владимир Мясников. Они стандартизировали подход по документированию внутренних систем в команде интеграционного тестирования "Мир Platform" с помощью модели C4. Платёжная платформа "Мир" представляет из себя десятки систем и сотни интеграций, за работоспособность которых отвечает команда Дмитрия и Владимира. Автору в статье разобраться новичку и даже опытному сотруднику в происходящем бывает не очень просто. И сегодня авторы расскажут, как помогают коллегам быстро и удобно получить информацию о их системах. Давайте разберёмся, что такое модель C4 и какие задачи она помогает решать. С чего начать, если вам поступила задача задокументировать большую систему? Но сначала небольшой дисклеймер: все примеры, использованные в статье, намеренно сделаны не похожими на настоящую архитектуру платёжной системы "Мир".
Так что же такое модель C4? Модель C4 - это подход к моделированию архитектуры системы, в котором основной акцент нацелен на простоту нотации и различные уровни абстракции. Простая и нестрогая нотация позволяет одинаково легко читать и моделировать диаграммы, а разные уровни абстракции подойдут как для бизнес-портал. C4 я оставлю в описании, в ней подробно описано, как моделировать системы. А цель статьи авторов - это рассказать, как они на практике применяют модель C4, и они хотят поделиться с вами накопленным опытом. Перед началом можно посмотреть на экран. Вот наши C4, собранные в одном месте, то есть четыре левела абстракции, и каждый из них начинается на букву "С". И, естественно, пока вы ничего не понимаете, давайте углубимся.
Итак, давайте смотреть на уровни абстракции. Первый уровень абстракции - это первая буква "С" - контекст. Диаграмма контекста. Это самый высокий и абстрактный уровень. Диаграмма контекста подходит для системами, взаимодействует документируемая система, и для чего нужны взаимодействия с другими системами. Давайте посмотрим легенду для диаграммы контекста, то есть какие элементы там могут использоваться. Посмотрите на экран. Первый элемент - это пользователь документируемой системы, такой прямоугольник с округлёнными углами и кружком в нём. Пишем, что это за пользователь и описание. Дальше у нас идёт такой прямоугольник синий - это документируемая система. Выше уровень абстракции, описывающий нечто такое, что приносит пользу её пользователям. Соответственно, в самом прямоугольнике мы описываем, что это за система и краткое её описание. И серый прямоугольник - это внешняя система, с которой взаимодействует документируемая система. Также у нас есть, конечно, стрелочки - это отношение между элементами диаграммы. Стрелка направлена от вызывающего к вызываемому. Примера каждого из уровней, конечно, будут, так что не переживайте, нужно дождаться.
Второй уровень абстракции - это containers. Диаграмма контейнеров. Диаграмма контейнеров подходит для пользователей, которым нужно понять архитектуру приложения без глубокого погружения в техническую часть. Это более полезная и обязательная абстракция при документировании системы. Цели диаграммы - это ответить на следующие вопросы: какие технологии использует система? Из каких контейнеров состоит система? Как контейнеры взаимодействуют между собой? Как контейнеры взаимодействуют с внешними системами? И как пользователи взаимодействуют с документируемой системой? По элементам у нас, конечно, есть сам контейнер - голубенький прямоугольник. Это некоторая самостоятельная часть системы, например, мобильное приложение. Есть хранилище данных, оно отображается в виде цилиндра. Практически во всех нотациях моделирования такая форма используется для отображения хранилищ и баз данных. Есть ещё один цилиндр, только он уже на бок повёрнут - это брокер или очередь сообщений. И есть группа контейнеров, из которых состоит документируемая система, её ограничивает пунктиром. Ну а также используются, конечно, все элементы, которые были у нас в диаграмме контекста.
Третья буква "С" в нашей C4 - это components. Диаграмма компонентов. Целевая аудитория этого уровня абстракции - это программисты и архитекторы. Перед её использованием рекомендуем посоветоваться с командой, возможно, она вам не нужна. Цели диаграммы: ответить на такие вопросы: из каких компонентов состоит контейнер? Как компоненты взаимодействуют между собой? Как компоненты взаимодействуют с внешними системами? И как пользователи взаимодействуют с компонентами? По элементам у нас есть компонент, конечно, голубенький прямоугольник. Это такая абстракция, из которых состоит контейнер. Тоже есть хранилище данных, тоже есть брокер или очередь сообщений, тоже есть группа компонентов, которые тоже пунктиром ограничивается. Опять же, контейнер состоит из этой группы компонентов. Есть пользователь документируемой системы, есть внешняя система, с которой взаимодействует документируемая система. И опять же, стрелки - отношения между элементами диаграммы.
Ну и четвёртая, последняя буква "С" в C4 - это код. Диаграмма кода. Диаграмма кода используется для низкоуровневой детализации системы. На официальной странице модели C4 рекомендовано использовать UML Class Diagram и Entity Relationship Diagram или схожие нотации. Про UML, кстати, у нас отдельный выпуск был, ссылочка в описании будет. Подробно сейчас UML не будем рассматривать, это целый свой мир. На примере мы посмотрим, а если нужно детальнее, то можете посмотреть уже в отдельном выпуске. При UML. Итак, классно, мы поняли, что это за буквы "С", для чего они нужны, что за уровни абстракции и какие в них есть элементы. Ну давайте поймём, что с ними делать.
Описываем свою первую систему. Работа по документированию системы следует начать с создания диаграммы контекста, то есть, естественно, с первого уровня. Моделирование диаграмма контекста особых сложностей не представляет и не требует больших временных затрат. Какие у нас будут шаги? Посмотрите на экран. Вот пример диаграмма контекста. В центре диаграммы мы размещаем элемент "система". В нашем случае это система заказа лекарств, максимальное такое общее понятие. В верхней части диаграммы размещаем пользователей системы. В нашем случае это администратор магазина лекарств и клиент магазина лекарств. По периметру системы размещаем элементы "внешняя система" - это формирование отчётов, система уведомлений, система картографии, разные системы оплаты, бухучёт и так далее. Почему они внешние? Ну, потому что нам нужно описать именно нашу систему заказа лекарств, но нам нужно показать, с чем она взаимодействует и кто с ней взаимодействует. Ну и между элементами проводим стрелки от вызывающего к вызываемому. Внутри стрелок описываем, какую функцию выполняет взаимодействие. Например, администратор магазина лекарств редактирует каталог лекарств в системе. В нашей клиент просматривает и заказывает лекарства в нашей системе. Наша система входит в системы оплаты платежа. В системе складского учёта запрашивает наличие товара на складе. Ну и так далее. Расположение элементов не является обязательным, но внутри команды авторы статьи стараются соблюдать единообразие. Этот комментарий вообще относится ко всей статье. Так, ну вроде бы тут проблем не возникло. Давайте двигаться ко второму уровню - моделированию диаграммы контейнеров.
Смотрим на экран. Тут уже поподробнее выглядит схема. В центре схемы размещаем элемент - пунктирную рамку. Пунктирная рамка как раз объединяет все контейнеры, которые вместе составляют нашу систему заказа лекарств. Фронт системы, например, веб-приложение и мобильное приложение, вписываем в верхнюю часть прямоугольника. Бэк системы в виде балансировщика, каталога лекарств, сервиса API и так далее, располагаем в центре. О хранилище данных, да, базы данных располагаем внизу. То есть, давайте частично рассмотрим один кейс, который у нас есть на этой схеме. Видим, что у нас клиент просматривает и заказывает лекарства, например, через веб-приложение. На стрелочке указываем, что запросы идут через JSON HTTPS. Веб-приложение перенаправляет запросы в балансировщик соединений. Балансировщик запрашивает каталог лекарств у каталога лекарств. Каталог лекарств уже связан с процессинговым. Он уже смотрит в базу данных, читает оттуда данные и записывает их туда. Ну и процессинг заказов окольными путями через сервис API, через балансировщик соединений, например, в системы уведомлений передаёт информацию о новом заказе или у системы складского учёта запрашивает наличие товаров на складе. И мы видим, что все наши контейнеры объединены пунктирной линией, потому что это всё система заказа лекарств. В оригинальной статье на Хабре, ссылку на которую, как я уже сказал, я оставил в описании, вы можете подробно посмотреть эту схему, позумить её, разобраться. Понятно, что это только пример, но он помогает понять концепцию.
Переходим теперь к третьему уровню - моделируем диаграмму компонентов. Снова смотрим на экран. В центре размещаем пунктирную рамку, и в нашем примере это шлюз оплаты - один из компонентов предыдущей нашей схемы. Внутри рамки размещаем уже компоненты, из которых состоит контейнер. Над рамкой размещаем источники данных, в нашем случае это брокер, подсистема, кавка. Про неё, кстати, у нас тоже отдельное видео уже есть, да и не одно. В нашем примере там проходит очередь заказов на оплату, и брокер как раз является входом. Он направляет запросы на оплату в наш шлюз. А в нижней части располагаем хранилище данных. Вот наши две бэдки, например, это у нас 1СД Oracle, где мы храним пользовательские данные, и такой же Oracle, где мы храним события. Но по периметру рамки размещаем внешние системы и контейнеры. Например, в нашем случае это группа систем мобильной оплаты. У неё мы запрашиваем проведение оплаты. Ну и по нашему примеру вы видите, какие в нашем шлюзе оплаты есть компоненты, как они связаны друг с другом, в каком направлении идёт обращение, какие компоненты с какой бэдкоп ответственны за общение с внешними системами, например.
Ну и мы подобрались к моделированию четвёртого уровня - диаграммы кода. Моделирование в нотациях UML Class Diagram или Entity Relationship Diagram (ERD) выходит за рамки нашей статьи, так как мы рассказываем только про C4 сегодня. Таким образом, в избежании избыточности мы этот раздел сейчас пропускаем. Мы уже об этом говорили. Если что, отдельное видео смотрите. И ещё разок, кстати, про ERD тоже отдельно, целая у нас статья есть, всё ещё в описании. Тут мы видим сущности, которые у нас есть, на примере четырёх сущностей: клиент, заказ, склад, отправки, курьер. Видим, какие есть атрибуты у них, и видим, какие связи выстроены между этими сущностями: один к одному, один ко многим, многие ко многим. Ну и так далее. В общем, есть вариации. Ну вроде бы круто, всё, но вообще не совсем. Для удобства навигации авторы рекомендуют использовать интерактивные элементы. Авторы покажут свою реализацию на примере Confluence. Первое, что мы делаем - это создаём переход из диаграммы контекста на диаграмму контейнеров. Вот пример. Я думаю, смысл тут понятен. Хочется просто на первом уровне кликнуть на систему "заказ лекарств" нашу и провалиться на второй уровень, посмотреть систему подробнее. Потом создаём переход из диаграммы контейнеров на диаграмму компонентов. Тоже кликаем на контейнер, проваливаемся в компоненты этого контейнера. Ну и создаём переход, конечно, также из диаграммы компонентов на диаграмму кода. Для компонентов следует использовать UML Class Diagram, для хранилищ данных следует использовать диаграмму баз данных или ERD. На экране пример с ER моделью, да, с ERD.
Ну а как авторы адаптировали нотацию C4 для нужд команды? Теория теории, но очень хочется послушать про реальный опыт. В этом разделе авторы рассказывают о некоторых ухищрениях и изменениях, которые помогают им лучше выполнять работу в части интеграционного тестирования. Первое, что делаем - это используем единообразное расположение элементов. Размещаем элемент "пользователь" в верхней части системы, размещаем хранилище данных в нижней части системы. Ну и размещаем внешние системы по периметру, обычно слева или справа. Второе - это стараемся делать небольшие диаграммы. Стараемся, чтобы диаграмма была размером А4, то есть полностью вмещала на экран монитора или могла быть распечатано для обсуждения. А если в диаграмме слишком много элементов, то объединяем схожие элементы и декомпозируем странички, как на примере на экране. Ещё авторы не используют диаграмму компонентов. Ну вот так тоже бывает. Авторы приняли решение внутри команды, что для их целей интеграционного тестирования не требуется диаграмма компонентов, и они не будут тратить на неё время. Вы спросите: "Зачем тогда нам всё это нужно?" Ну, потому что каждой ситуации свой подход. Очень важно знать все возможности для того, чтобы грамотно их использовать в нужной ситуации или грамотно не использовать. Также авторы используют диаграмму последовательности. То есть это всеми нами любимые UML sequence диаграммы. Команда авторов приняла решение использовать диаграмму последовательности вместо UML Class Diagram и ERD для описания интеграции между системами. Опять же, это только пример конкретной ситуации авторов, не стоит думать, что прямо нужно именно так делать. Какая-то команда будет использовать только ERD, а какая-то команда будет использовать и то, и другое. Также авторы декомпозируют. Если между системами много интеграций, то нет смысла проводить пять отдельных стрелочек. Ребята оформляют интеграции как одну стрелку и декомпозируют их на отдельной странице, как на примере на экране.
Ну и давайте немножко выводов. Команда авторов работает с десятками систем, и модель C4 позволяет им сэкономить время на чтение и поиск документации. Они могут получить всю нужную информацию буквально в три-четыре клика. Конечно, не бывает идеальных решений, и авторы сами пишут, что проблема их подхода - это повышение человеко-часов на документацию и необходимость постоянно актуализировать диаграммы. Ну, это всегда та цена за информативность и понятность, которую вы платите. В отрыве мы уже смотрели гивки, как у нас переходы между диаграммами построены, но давайте посмотрим итоговый пример, что должно получиться.
Ну а на этом всё. Спасибо, что послушали эту статью. Надеюсь, вам, как и мне, было интересно. Если понравилось видео, то поставь ему лайк. Ну и поддержи канал подписочкой. Ну а если хочется поддержать денежкой, тоже такое возможно, либо разово на ЮMoney, на Boost, буду очень благодарен. И не устаю говорить про наш Telegram. Напомню, что мы туда выкладываем аудио версии всех выпусков. То есть, выключаешь экран, кладёшь телефон в карман и по дороге на работу или на учёбу слушаешь. Или сны уже в наушниках. Ну всё, пока.