Transcription
Джокером, да это интересно. Ну, пишет мне, не обновляется постоянно. [музыка] Штатными средствами обновление есть, скачать там, установите, и всё, и он пропадает. А если скачиваешь новую версию сайта и просто устанавливаешь, если на сайте, если ты смотришь трансляцию, на всякий случай выключить там звук. Вот пробовал, например, проект либо, которая аналог Докера, но для того, чтобы для коммерческой разработки использовать, нет, не пробовал. Там такие прям развлечения, танцы с бубном возникают. Я пытаюсь всё это запустить, там ещё просто это очень сильно влияет непосредственно сам проект, приходится там подкладывать другие настройки, других каких-то вещей, связанных с этим. Почему не знаю, я счастливый пользуюсь, как типа это постфактум. Вот пришли, сказали: "Всё, используем". И вот, и приходится осваивать.
А мы уже тем самым временем онлайн. Ребята, рады вас поприветствовать сегодняшним солнечным, тёплым вечером. Вот буквально ещё пять минут, и мы скоро будем начинать. Вы можете сделать чай, кофе или что-то другое взять, или прямо водички. А также, не стесняйтесь задавать вопросы. Сегодня Саша нам будет рассказывать невероятно интересный доклад. Я его уже видел, и он потрясающий. Что Саша, что доклад. Вот, и не стесняйтесь писать ваши вопросы. Что на YouTube, и также у вас есть возможность зайти к нам, и мы будем обязательно их затаскивать в эфир и зададим либо по ходу, либо в конце непосредственно доклада. Слушай, я всё-таки старался, надеюсь, будет чем тебя удивить. Больше. Здорово, здорово. Супер, классно. Расскажи, что самое было сложно при подготовке этого доклада?
Да, в общем и целом, ничего такого сложного не было. При подготовке предыдущего доклада были сложности, но о них я там, наверное, расскажу в докладе. Основная сложность, что всё это развивается и так довольно активно. Какие-то фичи, которые там описаны в документации, это и всё так сделала, запускаешь, она не работает. Просто говорит, что здесь должен быть элемент группы. У меня, извините, там есть элемент группы. Ну и соответственно, поэтому я сейчас не стал брать. В принципе, хорошая практика не указывать контейнерах, указывать конкретно чётенько. Всё работает. Да, согласен. Супер, это очень интересно. Я ещё знаешь, я когда делал анонс в Твиттере, там пришёл Ваня, который, я уже забыл его фамилию, случайно. Вот, и он вылетел скептицизм по поводу вот непосредственно лицензии этого инструмента. Ты будешь рассказывать сегодня в докладе про лицензию? Мы посмотрим прямо онлайн. Можно задать мне вопрос, если я забуду, и посмотрим онлайн. Я, честно говоря, не пока не заморачивался. Супер, очень классно.
Да, у нас уже подключается, подключается народ, и буквально через три минуты. Расскажи, насколько было сложно вообще внедрять описание сервисов с помощью модели C4 непосредственно в компании? Я не могу сказать, что мы внедряли. У нас была задача, она ещё есть, идёт пока. Есть была существующая ландшафт, да, там такая микросервисная архитектура, там порядка 100-140 микросервисов всяких разных. Собственно, документации не было, и нас попросили сделать аудит. И вот описать. И как бы я вот долго выбирал инструмент, думал, как, что. Причём вот это всё C4 структура, мне было два подхода. Первый, так, что-то посмотрел, неглубоко, ник подумал, что-то не то, там начали рисовать. А потом как-то ещё раз я открыл, посмотрел более детально, понял, что на самом деле что удобно. Супер, классно.
А я предлагаю на самом деле начинать. Ещё раз небольшой дисклеймер для тех, кто нас смотрит на YouTube, не стесняйтесь писать ваши комментарии и вопросы. Мы будем обязательно затягивать эфир и зададим либо в конце, либо по ходу доклада непосредственно. Также у вас есть возможность подключиться для того, чтобы лично задать какой-то вопрос. Для этого у нас есть такой замечательный механизм, называется "И по этой реакции" будет сразу понятно, что вам нужно явно передать слово. А на этом я предлагаю начинать. Саш, мы готовы? Да, да. Хорошо. Сейчас я единственно запишу запись, потом [музыка] Так, мы ещё, я это всё вырежу, это будет вырезано. А вот, предлагаю начинать.
Всем привет! Я Гриша Скобелев, Java Back-end разработчик и организатор клубничного клуба. Между скобок. Сегодня у нас будет невероятно интересный доклад невероятно интересного гостя от Саши. Саш, привет! Расскажи немного о себе. Да, всем привет! Гриш, привет! Спасибо, что пригласил. Меня зовут Александр. Я работаю в компании Datamatica, занимаемся разработкой, всё такое. Да, до этого я разработкой занимаюсь 4, наверное, уже. До этого я 20 лет практически занимался внедрением и систем, но потом надоело. И супер, спасибо, что поделился. Ребят, задавайте ваши вопросы, пишите их в чатик, мы их обязательно затянем вверх. Я предлагаю начинать. Саш, тебе слово.
Да, тема нашего доклада - это описание, документирование, описание, моделирование архитектур, взаимодействие всяких разных сервисов. Да, и когда мы говорим о сервисной архитектуре, то это примерно всегда выглядит как-то так. Есть какой-то набор приложений, сервисов, есть базы данных, есть шины между ними. Пока сервисов мало, как бы, документация особо, в общем, не нужна. Когда их становится много, и документации нету, это становится проблема. И соответственно, вот возникает вопрос: "А как бы всё это делать теперь то, что мы наделали без документации описать?" Ну, и тут есть довольно много всяких вариантов разных. Да, там, написать документ, мы не рассматриваем, потому что документы никто не читает и не поддерживает. Значит, ну, и собственно, они наглядные, они удобные, и логично использовать диаграммы. С диаграммами тоже много вопросов. Да, сначала нужно выбрать нотацию, можно без нотации вообще рисовать, там просто такие квадратики, взаимосвязи. Можно взять UML, можно ещё какую-то. Дальше, собственно, вопрос: "А как эти диаграммы рисовать?" Первый, первый способ самый очевидный, простой - это графически в каком-нибудь редакторе, да, взять и нарисовать. Второй вариант - это есть такой подход "диаграммы как текст". Да, это мы в тексте описываем нашу диаграмму, и каким-нибудь плагином или программкой они [музыка] рендерятся графическое представление. Значит, ну, и соответственно, нужно выбрать инструмент, в котором мы будем делать. Зависит от того, подхода, какой мы выберем, графический или текстовый. Инструмент тоже есть разные, там Draw.io, Archimate Designer. Да, если мы говорим о тексте, основные там Mermaid, PlantUML. Значит, и допустим, мы определились, да, там с нотацией. Попозже об этом поговорим ещё более подробно. Значит, какие есть вообще проблемы со всем этим делом? Первое - это вот хочется иметь некую декомпозицию, потому что на одной диаграмме изображать все сервисы, все взаимодействия - слишком много, довольно ненаглядно, неудобно. Да, и мы хотим как декомпозировать, сначала там какой-то сделать, потом диаграмма конкретного сервиса, потом уже какие-то внутренности. И тогда получается, что при графическом, что при текстовом подходе нужно менять, потому что каждая диаграмма, она отдельно, и соответственно, приходится, если какие-то связи поменялись, то приходится менять диаграмму верхнего уровня и нижнего уровня. Это, ну, как бы занимает время, нужно не забыть. Поддержка этого становится довольно сложной. Ну, и что касается, например, графического представления, да, есть мы просто рисуем, то возникает вопрос версионирования. Тоже, как бы, кто поменял, когда поменял, это нужно какой-то там стратегию именования файлов придумывать и так далее. Соответственно, здесь сложность. Текстом попроще, можно закинуть всё в Git, да, и там всё видно, историю коммитов посмотреть, кто, когда, чего менял, зачем. Ну, вот по поводу аннотации, соответственно, вот UML, да, хорошая штука, но пользуются ей не всегда, так скажем. Почему? Потому что она сложная. Вот сейчас на слайде представлена только типы диаграмм, которые можно изобразить, довольно много. Есть структурные диаграммы, есть диаграммы поведения и так далее. Соответственно, во всех надо погружаться, и там понимать, как стать работает, да, как как рисовать, и какие, какие, собственно, типы диаграмм нужно выбрать. Вот там примерно как это выглядит, да, соответственно, изучая всё эту тему, я наткнулся на модель C4. Она оказалась довольно интересной, и концепция довольно интересная, и тулинг у неё довольно удобный. Значит, она была создана Саймоном Брауном где-то в 2000-х годах, и с тех пор он её как-то там развивает, продвигает, и можно найти его выступления на разных конференциях. Значит, вот у неё сайт. Она из себя представляет сильно упрощённую такую. Она основывается как раз концепции декомпозиции. Это [музыка] новое понятие, даже ноль. Она была когда-то в нём что-то рисовал. Значит, когда мы действительно рисуем разные уровни архитектуры, то есть верхние уровни в диаграмме, мы не видим каких-то деталей реализации конкретных сервисов. Когда мы смотрим диаграммы сервиса, уже видим эти детали. Это позволяет не захламлять, потому что на одной диаграмме много всего. Ну, как бы, на не неудобно. Значит, всего несколько сущностей есть. Есть люди, до которые взаимодействуют с системами, есть системы, есть контейнеры, да, ну, как бы, есть такой спор, да, там, не очень удачное название. Спрашивает: "Это Docker-контейнер?" Нет, это как бы такое понятие, да. Сейчас на нём расскажем. В рамках этой методологии, то есть это как раз можно сказать, что уровни, уровни есть. Самый высокий уровень - это система. Она состоит из контейнеров. Контейнеры стоят из компонентов. И, собственно, вот связи. Какие типы диаграмм предлагает методология? Первый тип - это System Context. Для основные есть дополнительные. Вот из основных, первый - это System Context диаграмма. Это описание сервиса в целом, с какими другими сервисами он взаимодействует. Контейнер диаграмма - это описание компонентов сервиса. Компонентная диаграмма - это уже такие, условно, классы, из которых состоит компонент, да, но там, не знаю, примитив, там, сервисы, контроллеры. То есть это не совсем классы, вот прям, если их много, да, это всё-таки какие-то более укрупнённые такие объекты, которые бы хотели бы видеть. Ну, и четвёртый уровень - это диаграмма кода. При этом самой методологии 4 каких-то нотации для них нет. Автор предлагает использовать стандартные UML-диаграммы для этих целей, если вам нужно. Ну, и в целом, как бы, компонентная диаграмма, диаграмма кода, они не очень распространены, потому что их сложно поддерживать. Например, компонентную диаграмму можно поддерживать, если там есть какая-то поддержка страны. В общем, в целом, почему бы и нет. А так, каждый раз, когда что-то меняется в системе, перерисовывать диаграммы, обычно этого не делают. Соответственно, такие диаграммы становятся бесполезными. И есть дополнительная диаграмма - это System Landscape диаграмма. Это такой "вертолётный" View, который показывает вообще сверху все все системы и как они взаимосвязаны. Есть ещё Dynamic диаграмма - это описание процесса. Это аналог [музыка] диаграммы, либо там в каком-то виде, наверное, SQL-диаграмма, не совсем с корейками. И диаграмма развёртывания. Как эти диаграммы выглядят? Вот System, начнём с вспомогательного Landscape. Да, вот он выглядит так. Это показывает, какие у нас есть системы, кто с ними взаимодействует, и как. Вот такой как бы вид сверху. Дальше есть диаграмма контекста конкретной системы. Здесь мы видим интернет-банкинг систему. Она взаимодействует с покупателем, взаимодействует с системой рассылок, взаимодействует. В целом, мы видим саму систему, видим все взаимодействия. Контейнер диаграммы - это диаграммы, которые уже раскрывают нашу интернет-систему и показывает её компоненты. Есть база данных, есть веб-приложение, есть мобильное приложение, есть сервис бэкенда, и эти компоненты показаны как бы на этой диаграмме уже более детально. Ну, и соответственно, это как компонентная диаграмма, которая там уже показывает какие-то кусочки, кусочки программы, каким-то образом сгенерированные, да, там, вот как вы решили скомпоновать. Так, но это диаграмма не очень часто встречается. Соответственно, диаграмму кода мы пропускаем. Динамическая диаграмма - она показывает последовательность взаимодействия. Кто-то кого-то что-то отправляет, дальше пересылает, он потом отвечает, и так вот по цепочке, как идёт запрос. Диаграмму коммуникации также есть вспомогательный тип диаграммы. Диаграммы развёртывания. Здесь показано, на каких, собственно, мощностях это развёртывается. Здесь показываются сервера, какие-то основные, основная база данных, реплики, веб-сервера, сервера приложений и так далее, где развёртываются наши приложения. Итак, мы сегодня, наверное, поговорим в основном по System Context и Container диаграммам. Значит, какие инструменты? То есть это C4 - это методология моделирования. Она определяет какие-то основные объекты, взаимосвязи и всё. То есть, ну, можно в чём угодно её рисовать. Какие у нас есть средства? Графическое, устанавливать, можно его подключить и рисовать, рисовать диаграмму. Есть текстовые, в PlantUML тоже есть плагин, можно в текстовом виде C4 рисовать. Ну, и соответственно, автор методологии предлагает свои инструменты и свой подход, я бы сказал, к построению всех этих диаграмм. Инструмент называется Structurizr. И он предлагает использовать не подход "диаграммы как текст", а "диаграммы как код". Соответственно, есть некие цели, разработанные, в которых можно, которым можно описать нашу диаграммы. И такие у этого подхода есть плюсы. Да, во-первых, идея в том, чтобы хранить описание систем в одном, как бы, возможно, и нескольких там DSL, позволяет связанных файлах. Также идея в том, чтобы отделить модель от представления. В DSL мы в основном описываем модель, отдельно представление отдельно. Все взаимосвязи, которые есть между сервисами, они описываются в модели. Представление уже мы сами выбираем, какие представления хотим видеть. Ну, вот что касается инструментов, самого Structurizr - это довольно удобный инструмент визуализации. И в чём ещё плюс использования DSL, до использования кода, в том, что это не конкретный формат диаграмм. Есть возможность из него выгрузки в разные форматы. Можно выгрузить картинки, можно выгрузить PlantUML, можно выгрузить нотацию C4 UML, которые с плагином показывается, можно выгрузить в формате Mermaid, куда-то там строить на веб-сайт. Всё довольно удобно. Наверное, мы перейдём сейчас к тому, как всё это выглядит. Соответственно, у меня есть, у меня есть просто папочка, и есть вот файл workspace.dsl, в котором мы все наши диаграммы и описываем. Вот он открыт. Да, кстати, для Visual Studio Code есть тоже плагин, который подсвечивает синтаксис. Значит, из чего состоит этот файл? Корневой элемент workspace. Дальше здесь есть возможность включить документацию, есть возможность включить Design Records. Об этом тоже посмотрим, как это работает. Дальше, собственно, описывается модель. Здесь мы описываем все наши системы, которые мы хотим описать. Предположим, что у нас есть некие веб-сайт интернет-магазина, который с которым взаимодействует пользователи. У нас есть, соответственно, сервис пользователей, который хранится информацию о пользователях, его транзакции, и есть какой-то API Gateway. Есть, и вот есть наш основной сервис, сервис, допустим, которым занимается наша команда - это сервис платежей. И этот сервис, он, идея в том, чтобы Мы хотим работать с несколькими провайдерами, да, он предоставляет единый API для веб-сайта, и уже логика работы, логика оплаты, она реализуется в нём. Битвы, логика работы с конкретным провайдером, она реализуется в отдельных сервисах. У нас есть коннектор к одному банку, есть к другому. Вот описание выглядит примерно следующим образом. Кстати говоря, можно группировать наши системы, как мы хотим, да, мы можем создать группу. Группы могут быть вложенными, это на диаграммах также отмечается. Соответственно, мы начинаем описание нашей системы. Берём, пишем Software System. Да, это ключевые, ключевые слова. Это в DSL, доставка твоя система. Дальше есть подсказка, дальше название, дальше какое-то описание, и дальше мы можем присвоить теги. О них я расскажу чуть позже, где их использовать и как. Дальше мы добавляем вторую систему, третью систему, точно также. Здесь, вот, допустим, что веб-сайтом наша команда вообще не занимается. Тоже мы знаем, что он состоит из там бэкенда и кэша. И есть сервис клиентов, которые тоже не в нашей зоне ответственности. Там есть бэкенд и есть база данных. И вот есть на этом группа наших сервисов, которые отвечает наша команда, и соответственно, вот они объединены в группу, и мы говорим, что это сервис платежей. Для чего нужен описание? И дальше мы описываем, из каких, из каких контейнеров состоит, там, кого по-хорошему можно назвать это компонентами. Из каких компонентов состоит наш наша система. Вот наша система также состоит из бэкенд приложения. Здесь формат описания немножко такой побольше, да, здесь есть ещё можно указать, помимо названия, описания, нужно ещё технологию, которая сделана. Соответственно, у нас есть бэкенд приложения, да, это Spring, допустим, есть база данных, есть какой-то планировщик, сервис платежей, допустим, для повторения каких-то не прошедших платежей, есть, и есть несколько адаптеров, коннекторов, да, к банковскому. У нас есть один банк, Бинбанк, да, есть какой-то маленький банк, другой отдельный коннектор. Все системы мы описали. Вот как бы у нас больше систем нету. В реальности их, конечно, больше. Сервис, соответственно, мы их описываем в модели. После того, как мы описали все системы, мы описываем взаимосвязи между системами. И мы говорим, что, например, пользователь пользуется веб-сайтом. Мы говорим, что наш гейтвей получает запросы от веб-сайта, да, и он хранит ответы от других сервисов, куда он трактирует. Мы говорим, что кастомер сервис получает запросы через день, получает запросы, и мы тоже можем указать технологию. Мы говорим, что кастомер использует базу данных. Вот тут очень важно указать. Вот что значит достаточно. Здесь, как мы говорили, вот сложность поддержки диаграмм, когда есть декомпозиция, что перерисовывать на многих уровнях. Здесь мы определяем связи на самом нижнем уровне. У нас кастомер сервис, он связи вообще нигде не участвует. Мы используем связи только его вложенные компоненты. Соответственно, у нас бэкенд взаимодействует с бэкендом гейтвея. Бэкенд взаимодействует с базой данных. Также он взаимодействует с Kafka, что-то оттуда получает. Тут есть проблема, о которой я расскажу. Дальше у нас есть наш платежный сервис, который тоже через день получает запросы [музыка] хранит у своей базе данных транзакции. Он взаимодействует с сервисом клиентов, получает оттуда информацию о клиенте, взаимодействует с Kafka, отправляет статусы платежей. Есть у нас ещё дуллер, планировщик, который тоже взаимодействует с базой данных, получает оттуда зависшие платежи и отправляет их опять же. Ну, и два наших коннектора, они взаимодействуют уже с внешними системами. Взаимодействие. Таким образом, мы описали всю нашу модель. Мы описали все наши системы, и мы описали все взаимодействия между системами. Здесь вообще никакие диаграммы. Дальше идёт блок, собственно, представлений. И здесь мы показываем, какие диаграммы мы хотим увидеть. На самом деле, в общем случае, да, такое описание выглядит примерно так. Вот System Context. Мы хотим увидеть диаграмму систем уровня System Context вот этого сервиса. Назовём её так. Какое-то описание этой диаграммы. Пишем: "Хотим включить всё, хотим, чтобы отработала Fallout, и всё достаточно". В общем, этих двух строк. Но тут есть некоторые проблемы, которые мы сейчас посмотрим. Таким образом, мы всё это описали. Дальше, вообще, хотелось бы, конечно, посмотреть уже в графическом виде. Поэтому мы, наверное, перейдём. Есть инструмент. Есть инструмент для отображения. Наверное, мы сейчас перейдём на слайд. Вот так, так. Какие инструменты вообще Structurizr предлагает? Первый инструмент - Structurizr Lite. Это такое вот сервис-приложение, которое можно запустить в Docker, да, и отдать ему этот наш DSL, и там всё увидеть. Есть приложение on-premise, да, которое позволяет в принципе развернуть его в компании, и там есть уже пользователи, можно настраивать разграничение прав доступа этих [музыка] workspaces. Вот этих может быть много. Соответственно, мы настраиваем доступ, какие пользователи имеют доступ. Есть облачный сервис, который, в общем и целом, очень похож на on-premise, но там есть какие-то дополнительные фишки, но он платный. Там есть дополнительные фишки типа авторизации и что-то такого рода. Но по функционалу, в общем и целом, можно сказать, что on-premise очень похож. Есть ещё консольные утилиты, так и, которая позволяет данные в on-premise, да, также она позволяет делать выгрузку либо из DSL файла, либо из сервиса в разные форматы, там картинки, Mermaid и так далее. Таким образом, у нас есть этот файлик, да, есть папочка, и мы хотим сейчас воспользоваться инструментом первым - Lite. Мы просто хотим у себя на машине там что-то запустить. Соответственно, мы выполняем команду. Я запускаю в Docker, да. Здесь, в общем и целом, особо ничего не нужно, один порт и смайпить папку, где у нас лежит файлик с DSL к внутренней папке Docker. Собственно, всё, да. Соответственно, вот есть сайт C4. Здесь можно посмотреть там типы диаграмм, какое-то описание, да, идею, в общем и целом. Здесь есть там чек-лист, например, по поводу диаграммы ревью. Здесь можно посмотреть для себя, если у меня там заголовок, если у меня там легенда и так далее. Тоже очень полезно, чтобы ничего не забыть. Того мы переходим 88. [музыка] Саша, пока он грузит, может, ответишь на вопрос? Задавали вопрос: "Где хранить описание? Это вместе с проектом или это какой-то отдельный проект?" Ну, смотри, это вопрос, на самом деле, не очень простой, да. Всё зависит от масштабов. Я думаю, что если это такой какой-то, вот, не знаю, команда решила у себя использовать вот этот инструмент, чтобы писать свои сервисы, твоя, в принципе, может хранить в одном из проектов или отдельно. Но если, в общем и целом, хочется чего-то большего, да, то имеет смысл поставить просто on-premise решение, и все будет храниться, условно, сервер, где будут храниться все компании, там можно заходить, их редактировать, смотреть. Вот мы, он всё открылось, да. Почему не видим диаграмму? Потому что у нас есть папочка Docs, где также можно хранить, собственно, и документацию к проекту, какому-то. Документация представляет себя из обычной Markdown файл. Смотреть, и сервис также показывает эту документацию. Можно вставлять картинки, можно вставлять ссылки на диаграммы, живые, живые ссылки. То есть мы поменяем что-то в диаграмме модели, здесь тоже всё естественно обновится. Какое-то описание. Значит, переходим к диаграммам. Этот сервис написан на Java, да? Да. Значит, сервис написан на Java, и в этом тоже есть плюсы, потому что можно что-то делать, на самом деле. [музыка] Значит, вот у нас открылся. Если посмотреть на наш файлик, да, DSL, мы определили в юстининский первом, да, и вот он как бы есть. Он очень некрасивый, такой, он некрасивый специально. Значит, почему так всё отрисовал? Потому что здесь не включен автолайт, и он просто его не применил. Для чего я сделал? Для того, чтобы сказать, что на самом деле автолайт есть, и в самом интерфейсе вы можете взять, там выбрать. Во-первых, здесь есть разные имплементации, есть разные варианты, и мы можем сделать. И, собственно, вот он. Да, вот у нас есть покупатель, он взаимодействует с сайтом. Это такая верхний уровня обзор всех всех наших сервисов. Вот у нас группа Payment Tab, вот общая группа, да, где где все наши сервисы. Это какие-то внешние сервисы, и, собственно, автолайт я не включал, чтобы показать, что можно здесь самим как-то там двигать, да, чтобы тоже можно убрать всё это. Если автолайт применяется при входе, то здесь уже, по-моему, ограничены возможности по перемещению. В общем, можно всегда применить. И, собственно, у нас здесь есть диаграмма для всех сервисов, и контекстной, и уровня контейнеров. Посмотрим коннекторы, не очень интересно, не очень простые, да, взаимодействие платежей с внешней системой. Диаграмма контейнер тоже мало имеет смысл в этом случае, потому что потому что стоит только у него нет компонентов. К маленькому банку всё аналогично. Какой там есть, да? Нас интересует в основном сервис платежей, самое интересное, да, вот там посмотреть на эту диаграмму. Какие здесь есть вообще инструменты? Во-первых, мы там смотрим, и там ничего не понятно. Как на какой сервис мы смотрим. Здесь можно посмотреть, вот включить, и он подсвечивает тот сервис, который она сейчас находится в контексте на этой диаграмме. Есть несколько проблем, на мой взгляд. Первая проблема заключается в том, что здесь отображаются другие сервисы, с которым взаимодействуют наш сервис платежей, например, сервис клиентов, да, но так как сервис платежей взаимодействует с гейтвеем и сервис, то он здесь тоже есть. Поскольку есть связь между сервисом клиентом и API Gateway, мы эту связь тоже видим. Что мне кажется, на самом деле, не совсем правильно для сервиса платежей. Ему, вообще говоря, я когда смотрю на эту диаграмму, мне всё равно, как сервис клиентов взаимодействует, взаимодействует. И вообще, потому что в данном случае мы смотрим на диаграмму платежей. А это вот первая проблема, с которой я столкнулся, да, и на самом деле, в неё нашлось решение довольно элегантное. DSL он очень такой довольно мощный, и здесь можно, здесь можно настраивать представление, да. И вот эта проблема решается на самом деле добавлением трёх строчек. Здесь мы говорим: "Добавляем всё". Здесь мы говорим: "Исключаем вообще все взаимосвязи". И дальше говорим, что мы хотим добавить взаимосвязи только нашего сервиса. Мы добавили, сохранили, обновили. Платежей выглядит уже гораздо лучше. Сервис платежей есть какие-то коннекторы, здесь есть клиент. Мы видим, что связи между ними больше нет, что в общем-то для этой диаграмма хорошо. Забегая вперёд, скажу, что на компонентной диаграмме я столкнулся с точно такой же проблемой, и тоже нашлось решение. Ну, собственно, первое решение придумал сам. Там можно по тегам исключать либо включать то, что мне нужно. Но пока мне очень удобно, потому что потому что нужно для каждой диаграммы прописывать тег конкретной системы. Можно добавить такую строчку, которая говорит, что мы хотим исключить все связи между сортовой системой со своей системе, то есть не на уровне контейнеров, на уровне систем. И если мы обновим, то тоже все лишние связи, в общем-то, пропадут. Сервис платежи, да, у нас уже нету связи между сервисом клиентом, что гораздо как бы облегчает восприятие диаграммы. Соответственно, первые проблемы мы решили, и она решается тем, что DSL довольно мощный. Забегая вперёд, можно сказать, что где-то даже специально оставил, да, здесь можно вставлять скрипты на Groovy, Kotlin и Ruby заявлен. Скрипт документация написана, что вроде не поддерживается, и здесь можно делать вообще всё, что угодно. Там можно убрать unclutol и
Скриптом добавить те системы и те связи, которые мы хотим, если не получается что-то сделать встроенными средствами, а встроенные средства довольно мощные. Здесь как раз вот можно там по типу системы. А я говорил о том, что у нас есть теги, мы можем отыгрывать нашу систему – это External System, да, там это страх, чуйка. И здесь точно так же можно задавать какие-то критерии по тегам. Ну, в общем, документация довольно подробно всё расписано.
Итак, первую проблему мы решили: мы убрали лишние связи, которые нам не нужны. Да, какая у нас есть ещё проблема? Есть проблема... не проблема, а задача. Всё зависит от того, что бы вы хотели описать. В общем и целом, не рекомендуется добавлять сюда какие-то инфраструктурные вещи. Ну, там, например, какой-нибудь Prometheus точно не стоит того, что он захламит диаграмму, потому что все сервисы связаны с ним, это будет куча стрелок. В общем, и понятно, что в общем налоги мы собираем метрики через Prometheus. Kafka – немножко другой случай, и нужно принимать решение при описании той или иной системы: стоит её добавлять или нет. Почему плохая идея? Потому что она скрывает взаимосвязи. Вот у нас сервис платежей отправляет статус платежей в Kafka, да, и мы не знаем на самом деле, какие сервисы их получают. И поэтому можно как бы Kafka не рисовать, да, нарисовать здесь напрямую какой-нибудь... что мы отправляем это сервис клиентов, на стрелочке написать уже, что отправка идёт через Kafka. Вот такой вариант тоже есть, и он более предпочтителен. Но надо понимать, что это более затратно на поддержку диаграмм. Потому что при изменении чего-либо, каких-то взаимосвязей между сервисами, да, их нужно будет, естественно, в диаграмме отражать. Когда мы пишем в Kafka... Ну, как бы, Kafka, Kafka, ты кто там читает? Ну, то есть, добавился ещё один сервис, условно, да. Так мы записали в Kafka, и новая команда разработала новый сервис, который наши же сообщения читает, никаких своих целей. Да, мы свою диаграмму не трогаем, но при этом мы не видим этой взаимосвязи. А если мы хотим её увидеть, то, соответственно, нужно как-то узнать, что теперь и этот сервис читает наши сообщения, на диаграмму добавить взаимодействие нашего сервиса с тем сервисом, попросить ту команду в свой сервис включить взаимодействие с нашим, чтобы мы увидели.
И третья, третья проблема на этой диаграмме. Ну, что, собственно, как бы мы вот решили описать сначала подход от единиц диплома. Да, вот у нас как коннектор к одному банку, второму – это отдельное приложение, мы выделили в отдельную систему. Но на самом деле, и сгруппировали сервисом платежей. Простой. Так можно, да, но много лет этого пользы. Если мы посмотрим на сами, на сами эти коннекторы, в общем целом, они диаграммы из трёх квадратиков. Поэтому имеет смысл нашу диаграмму переписать. Мы можем их убрать как самостоятельные системы и просто добавить в виде коннекторов к нашему приложению. Тогда, соответственно, группа нам тоже не нужна. Группа не нужна, и мы можем... не можем, должны удалить ещё вот эти представления, иначе будет ругаться, говорить, что не найдена такая система. Собственно, всё. Но тут каждый должен опять же сам решать, какой уровень детализации и как группировать: там по элементам развёртывания, по командам, по каким-то, не знаю, логическим связям между системами. Самый, наверное, такой правильный путь. И вот мы, если посмотрим, опять же, мы поменяли несколько строк кода, и диаграмма сразу перерисовалась. И эта диаграмма перерисовалась, и эта диаграмма рисовалась. У нас как бы сразу видно, что, значит, платежей он взаимодействует с коннекторами, а коннекторы взаимодействуют уже вот с банками. Мы на этой диаграмме уже видим, что наш сервис платежей он взаимодействует с банками, а не с коннекторами. А эти проблемы мы решили, да.
Ну, тут, собственно, есть ещё одна проблема, что наши как-то некрасиво. Эту проблему тоже можно решить. Здесь есть темы и стили. Соответственно, мы здесь говорим, что мы хотим использовать диффузную тему и дальше переопределяем стили, что там все элементы должны быть квадратиками с закруглёнными углами, что человек должен быть в виде человечка, что у внешних систем у них должен быть такой цвет фона, такой цвет текста и так далее. Что базы данных у нас должны выглядеть как цилиндры. И если мы сделаем, то превращается... на самом деле должно работать, и я проверял. Возможно, там что-то где-то что-то кэширует, вот какой-то глюк мы словили, да. По-хорошему, это должно выглядеть всё, всё, всё, всё, всё. Ну, в принципе, можно сделать вот так. Во всякий случай, для чистоты эксперимента сейчас это... Да, ребята, воркшопы проводить – это вообще нереально сложно, и Саше хочется сказать вдвойне большой респект за это. Вот обычно всё так бывает, демонстрацию что-то идёт не так. Сейчас удалим то, что он нагенерил в своей папочке, да, и с чистого листа, с чистой сейчас попробуем. Это, знаешь, это ещё может быть на самом деле там просто, например, клиент браузера, фронтен как-то закэшировал. Там постоянно кэши используется. Ну, теоретически может быть, да, тут много где каких-то... Так, значит, удачных с точки зрения использования. Но сейчас придётся подождать, пока он... Если есть вопросы, я готов ответить, пока он думает. Смотри, были вопросы, много хороших вопросов было, мы их все обязательно ещё соберём. А, кажется, всё загрузилось, да. Сейчас уже немножко прогрелся, проект развивается, и нет, подсказывает, что, возможно, нужно сохранить DSL, controls нажать. Да, да, спасибо. Открывался просто, мы не сохранили файл. Сейчас работает без перезапусков. Произошла магия. Спасибо огромное. Соответственно, у нас всё подсветилось, так всё как бы гораздо приятнее. И какие-то инфраструктурные вещи. И сейчас давайте перейдём к нашему прекрасному сервису платежей, посмотрим, как выглядит сервис платежей. Там можно посмотреть систему ВКонтакте, мы можем посмотреть контейнеры, да. База данных выглядит как база данных, внешняя система выглядит серым. Ну, так гораздо приятнее. Соответственно, вот стили, да, рекомендую пользоваться, и они очень удобно как раз вот через теги настраиваются. То есть, мы можем для всех элементов задать, для сортовая система что-то можем задать. И, соответственно, вот у нас был тег Internal System – это на самом деле так. И мы говорим, что внутренняя система. Что ещё хорошего? Документацию посмотрели. Кстати, можем всегда вернуться, нажать, и вернёмся в документацию. Мы не посмотрели, мы не посмотрели, не посмотрели вот такое представление. На самом деле, можно всегда его открыть и посмотреть наши системы. Видео тоже немножко долго первый раз загружает. Да, вот у нас такой прекрасный граф получается. Здесь можно двигать, смотреть чего-то. То есть, вот как так видно, видно, как всё это связано. И есть ещё такая прекрасная штука, как Architecture Decision Records – это некоторые MDF-файлы, где мы записываем и архитектурные решения, мы когда принимали, и почему, какой из какие варианты мы рассматривали, что в итоге выбрали. Довольно удобная штука. Вот их я стал использовать на практике, потому что на память я уже не надеюсь. И здесь можно их подключить и как бы хранить и посмотреть. Да, если мы сейчас откроем, здесь, соответственно, у нас тоже есть какие-то вот решения, да. Документированием. Нам нужно определиться, как документировать систему. Будем использовать C4, да, и структура технологии делать. Как будем делать авторизацию? Но сразу видно, что это... это решение уже не... не актуально. Можем посмотреть другое какое-то решение. Вот в авторизации здесь вот оно принято, да, и видно, что оно как раз перекрывает предыдущее. И мы говорим, что нет, бейсик не будем, будем использовать OAuth 2.0. И как это ещё дополнительное, вот ко второму, да, вот дополняет второе. Какие технологии мы используем? Можно использовать Kotlin и там Go, если очень хочется, да. И можно также посмотреть фотографии, какие у нас есть решения авторизации и как они между собой связаны. Довольно удобная штука и прикольная, чтобы потом не вспоминать, зачем же мы так сделали, если комментировать куда-то положить. Очень удобно. В целом, в целом, наверное, по инструменту Light всё. И теперь вот хотел бы я несколько слов сказать по поводу остальных инструментов. Остальные инструменты – это у нас сервис. Сейчас мы закроемся, остановим наш контейнер, да, и он прямо тоже доступен в виде докер-образа. Мы можем взять его и запустить. Здесь воспользуюсь уже там `cat`. Ну, то есть, собственно, исходники вы тоже открыты, тоже есть на GitHub. Можно собрать варку свою и уже положить там, например, свой там `k-test` запустился. Что из себя представляет? У нас нету... нам нужно войти в систему. Войти в систему. Стандартный пароль. Мы заходим в систему и можем создать новый. Вот мы создали наш прекрасный workspace, да. Соответственно, у нас он появился. Можно найти там settings и посмотреть. Вот у него есть какой-то айдишник и есть ключи доступа к нему. Соответственно, мы можем это делать всё скопировать. И сейчас мы попробуем наш DSL, который мы сделали, залить в One Secret. Соответственно, для этого мы воспользуемся третьим инструментом – это CLI. [музыка] Здесь я уберу документацию, да, потому что я эти папки не переносил, но в общем и целом можно их также перенести и всё загрузить всё вместе. Дальше мы заходим. Возможно, запись, запись какая-нибудь нагружает. Так. И вот у нас есть [музыка] команда, где мы говорим, что на этот URL, где у нас развёрнут workspace 1, ключами доступа такими, которые можно смотреть в настройках, мы хотим загрузить наш файл. Делает. Вот у нас появились наши диаграммы прекрасные. Мы находимся в нашем workspace, можем зайти в диаграммы и, собственно, увидеть ту же самую картинку. Здесь дополнительно можно перейти в режим редактирования. У нас автовок был отключен. Здесь дополнительно можно ещё делать, делать, делать ревью. Мы хотим сделать диаграммы и там чего-нибудь. [музыка] [музыка] Собственно, всё. И дальше можно какую-то ссылочку с этим ревью кому-нибудь отправить. В целом, здесь вся та же самая функциональность, что и в Light, но здесь [музыка] можно создавать много воркспейсов, можно разграничивать доступ. Наверное, ты даже были настройки, настройки, настройки пользователей. Пока создан один пользователь. Соответственно, здесь их можно настроить и тогда разграничивать доступ. В общем и целом, вот как это выглядит. Наверное, не настраиваются файлики. Можно посмотреть, как это настроить. Значит, соответственно, вот такой инструмент для [музыка] для совместной работы, для большого количества. Если тот был такой сервис, то это... Давайте мы ещё посмотрим. Значит, в общем и целом, всё, что я хотел рассказать, я, наверное, рассказал. Даже мы запустили версию, загрузили туда то, что мы сделали, остальные диаграммы, проверим, что всё есть. Вот, да, всё есть, всё прекрасно. Значит, всё работает. Имеет смысл, наверное, информация о... об этих продуктах можно посмотреть на сайте `structurizr.com`. Да, и я бы хотел, наверное, ещё пробежаться по самому GitHub, какие здесь есть репозитории, потому что я... мы не рассказал по поводу Java. Это плагин, плагин. Сейчас сделаем Stars. Вот первое то там DSL – это как раз описание этого языка, да. И здесь есть что... Что хорошо? Здесь есть документация, и основные здесь вещи – это, собственно, и вот эти две самые полезные ссылки, которые я использовал для изучения. Дальше, дальше есть такая штука, как Structurizr Java. Это тот же самый DSL, но только в виде аннотаций на живом коде. Соответственно, аннотации и кода тоже, да. Здесь есть пример. Здесь можно вот сделать, создать workspace, добавить туда модель, в модель добавить пользователей, добавить системы, добавить ещё что-то. И как бы я на самом деле с этой штукой не особо работал. Почему? Потому что я работал с Light-версией, и там удобнее использовать DSL. Как бы здесь не очень понятно, где, если намного сервисов, то в каком проекте вот этот здоровый код делать. Но когда мы говорим on-premise, да, то здесь можно как раз выгрузить вон прямо всё это дело. В каждом сервисе будет описание его, и дальше они как-то там срастутся, даже по идее срастаться в этом смысле в единое целое. И также здесь есть всякие процессоры аннотаций. Можно попробовать навесить аннотации собственные. Можно попробовать подцепить аннотации Спринга типа `RestController` или `Controller`, да. И вот эти вещи он загрузит уже в качестве диаграммы третьего уровня, то есть диаграммы компонентов. И вот здесь как раз может быть это удобно, потому что самому рисовать в DSL и диаграмму компоненты совсем неудобно, потому что мы меняем код, и надо тогда здесь всё поменять, да. Если он сам сканирует аннотации и вставляет эту диаграмму – это довольно удобная штука может получиться. Но сам я не пользовался плотно живую версию. Собственно, это интерфейс командной строки. Это для Dot. Это то же самое, что для Java. Light – это первый инструмент, которым мы пользовались. Java Extensions – это какие-то же экстеншены Java, да, там какой-то Spring-процессор как раз, который подбирает. Здесь есть проект с примерами, довольно интересный. Можно посмотреть, также там какие-то подчеркнуть, как что-то описать, потому что документация не всегда понятно, проще смотреть примеры. И вот довольно удобно, здесь есть несколько примеров. Также есть проект для приёма, то есть мы можем скачать его и, собственно, сбилдить его на машине в файл и запускать. А в общем и целом, наверное, всё. Всё, что хотел, я рассказал. Готов ответить на вопросы. Последний слайд с материалами – это как раз вот описание, где можно посмотреть какие-то материалы найти или ещё что-то: статьи, доклады, описание сама методологии, какие-то полезные штуки. Супер, выглядит невероятно круто. Мы соберём все ссылочки, обязательно их приложим к записи. Ребята, я напомню, кто с нами в Zoom, у вас есть прекрасная возможность сделать Raise Hand для того, чтобы задать вопрос. Это будет явным сигналом о том, что вы хотите задать вопрос, и вам нужно передать слово. А ребята, кто смотрит на YouTube, не стесняйтесь тоже писать вопросы, обязательно затянем в эфир. Пока народ думает, тут был хороший вопрос по поводу... во-первых, прекрасный вопрос от меня про лицензию. Ну вот, смотри, про лицензию как раз мы хотели посмотреть, и я зашёл сейчас в проект. Здесь то же самое, да. И напомню, что MIT-лицензия – это вы можете использовать это в коммерческом ПО, но нужно будет, да, указывать, что вы используете какой-то продукт. Так что, в принципе, хорошие лицензии. Самое главное, что вы не обязаны раскрывать свой. Да, да. А также был хороший вопрос по поводу того, что ты немного затронул про графические варианты. Расскажи, какие были критерии выбора между графическими именно DSL-написанием? Почему ты выбрал всё-таки именно DSL? Ну, я выбрал, в принципе, текстовый, потому что мне как-то, не знаю, удобнее всё это хранить в тексте, да. И когда это там рендерится чем... То есть, условно, я там меняю какие-то... захожу сюда, да, даже если от этого абстрагироваться, вот C4, да, там же мне как-то удобнее, да. То есть, меняю какие-то стрелочки, и в общем и целом диаграмма сама перерисовывается, ничего перерисовывать не надо. Поэтому текст. А DSL – потому что... потому что он ещё удобнее. Здесь мы не рисуем диаграммы вообще, мы делаем взаимосвязи между системами, и дальше мы просто говорим, какие представления мы хотим видеть, и система сама подцепляет эти взаимосвязи. Как вы... Если вы обратили внимание, конечно, что мы не описывали взаимосвязи между сервисами, мы описывали взаимосвязи между уже компонентами. А при этом на систем-контекст диаграммах все эти взаимосвязи были. Соответственно, там очень удобно: там в одном месте поменял – все диаграммы перерисовались. Спасибо, спасибо за твой ответ. А также есть ещё такой, мне кажется, философский извечный вопрос: а кто все эти сервисы должен описывать – аналитик или разработчик? Ну, это вопрос, на самом деле, не ко мне, а к командам. Всё зависит, наверное, от того, того, когда мы описываем сервисы. Если у нас сервисов нет, и мы проектируем только какую-то систему, то, наверное, аналитик, может быть, даже архитектор. А если у нас уже всё это есть, и нам нужно по факту сделать документацию, тут есть варианты: можно аналитика попросить, можно и разработчику, в принципе, описать. Особенно если рассматривать вариант on-premise и разобраться с Java, Java-аннотациями, то разработчику ещё будет проще. Мне нужно. Супер. Есть ещё хороший вопрос касательно того, что а есть возможность сделать ссылки на внешние DSL? Ты говорил о том, что можно встраивать Kotlin, Groovy, Java. Может быть, он может и DSL, да? А, да, значит, здесь... Здесь мы перейдём в Slim, мы перейдём в... Честно говоря, не помню. По-моему, это точно есть. Здесь есть раздел про скрипты. Скрипты, кстати, тоже могут быть в... как заян-лайне, на самом деле, вот этот вариант, так и в внешних файлах каких-то. Мы можем добавить... Наверное, это референсы, да, было, было. Можем добавить рядом с этим скриптик соответствующим расширением КТС. Здесь просто добавить скрипты, ссылку на него, и он подтянет. Значит, так вот, экстеншены. Вот есть. Соответственно, мы можем описать какие-то базовые вещи в одном воркспейсе, да, а более там детальные, остальные описания других сервисов мы можем наш workspace extended от другого workspace, и он подтянет туда все, все данные. У Алекса была поднята рука. Алекс, может, ты хочешь доуточнить вопрос или ещё что-нибудь сказать? Нет, Александр отлично ответил, собственно, то, что я хотел. У меня вопрос именно был, что если у вас есть микросервисы в разных репозиториях, как их между собой прикидывать? Александр всё ответил, спасибо. Это может быть, да, это может быть не единый документ, может быть много, и они могут цеплять друг друга. Значит, давайте немножко о недостатках поговорим. Какие-нибудь удобства понятно, да, можно это гибкая штука, да, и там скрипты можно и так далее. Но недостаток в том, что она на самом деле активно ещё развивается, и какие-то вещи меняются. Во-первых, я когда готовился к другому докладу, например, вложенные группы не работали вообще, хотя в документации было написано, что ещё поддерживают. И что ещё хотел сказать? И, соответственно, документация не всегда актуальная, и какие-то вещи, например, раньше здесь предлагалось наши сервисы... Вот есть какие-то внешние сервисы, да, есть наши сервисы, которые мы хотим как-то сгруппировать, показать, что это наша, да, предлагалось здесь делать отдельный элемент, который назывался Enterprise, который мог быть один на всю модель. Но теперь... То есть, соответственно, и DSL, и инструменты все развиваются, какие-то глюки появляются, какие-то исправляются. Вот это, наверное, в определённом смысле недостаток, потому что мы сейчас описываем, описываем, потом там бац, и что-то, что-то какая-то фича пропадёт, новая версия работать не будет. Начал говорить про недостатки, ты стриггирование, тебе слово. Да, я, я ожидал этого момента, по-любому он должен был наступить. Сразу такое. Я сам люблю C4, я его использую на самом деле регулярно, и ценность, которую я услышал, самое, самое главное преимущество C4, которое появилось просто при его задании – это обучение разработчиков, инженеров, в принципе, пониманию контекста. Потому что представление может быть ограничено определёнными элементами, и туда не надо... отдыхать не приколочено, что позволяет ребятам и строить свои системы, зарабатывать лучше, и, в принципе, писать документацию более понятно. До этого инструмента этого на рынке просто никто не умел. Я использую в повседневной работе по-хорошему, причём ребята обучаются, показано на экране. Вот, но Structurizr в том виде, в котором Саша показывает, если честно, вот особенно в природе DSL, я не могу согласиться с тем, что это хороший инструмент. Большой комментарий писали, что ребята прочитали в чатике. Вообще Structurizr – это попытка работать на уже существующих моделях, собственно, вторая история. И в нём нет много всего вместе. Во-первых, модель там... хорошо, что модель есть, но инструментарий для модели, в принципе, как код моделировать невозможно. Это показано такими инструментами, как... Как необходимо [музыка] атрибуты, необходимо фильтровать, необходимо навешивать определённые правила, необходимо связывать элементы с разных департаментов, необходимо привязывать бизнесовую составляющую, функции, процесс, коммуникации, стейкхолдеров. Этого всего C4 нет. Он ориентирован на взаимодействие, по сути, рассчитан на 2-3 вида представлений из всего многообразия, которое есть в архитектуре в целом. Описание, которое предлагает, и файлы, которые существуют на рынке – это общее направление, которое сейчас все пробуют использовать, но он привязан к диаграммам, по сути. И архитектурная документация включает огромное количество дополнительных вещей. Плюс мы учитываем весь элемент миграции. Любая архитектура постоянно мигрирует, трансформируется, и всегда есть проблема [музыка] что у нас уже есть, что у нас будет, и какие сейчас происходят эти изменения. Так что это... Не говоря уже о том, что сам инструмент Structurizr, если поработать с ним больше чем пять минут, оказывается, что после 30 элемента модели он начинает тупить. Рендеринг на самом деле многие браузеры начинают уже с огромными задержками выполнять. Ну, и трассировку автоматически выполнить тоже очень сложно. Это просто первое, что хотел бы просто. И, к сожалению, инструментов на рынке, который, в принципе, закрывает все эти проблемы, тоже существуют. Все пытаются сейчас сделать, разрабатывают подходы, разрабатывают, чем как бы C4 не является. Ждём, когда появится хоть что-нибудь. Прокомментировать на мой поток. Понятно, что есть какие-то недостатки, да, там. Ну, не знаю, я, наверное, штук 40 сервисов описал, и в каких-то там супертормозов даже у меня загрузилось нормально из квадратов и стрелок. По поводу описания какой-то архитектуры to-be. Ну, я не знаю, возможно, не пробовал, но почти уверен, что получится это сделать с помощью тегов. То есть, можно навесить там какие-то теги, там, где прийти этот теги там to-be, да, и сделать отдельное представление для будущей архитектуры, для там текущей, условно. Ну, да, на это зарабатывать надо свои подходы на основе существующего инструмента, который никак не повторим, на который нужно вешать туллинг, скриптинг, валидацию, чтобы это было консистентным, потому что менять диаграмму будет несколько десятков человек, если компания не стартап, и проконтролировать эти изменения мы не можем. Ну, да, есть, есть определённые, конечно. То есть, это инструмент, он довольно гибкий, позволяет сделать что-то, но при этом, конечно, да, если мы говорим о том, что авторов очень много, то что-то дополнительно нужно делать. Мне кажется, такая история про то, что попробуйте сами и скажите, как на ваш взгляд. Да, и ещё можно продолжить, на самом деле, обсуждение на эту тему непосредственно в нашем чатике. Ну, для небольших, на самом деле, вот довольно удобно. Удобно то, что он интерактивный. Здесь можно, например, я не знаю, войти сюда, нажать сюда, и он там вот переходит к другому уровню. Не доработают, правда, чтобы список можно было по папочкам раскладывать всех этих представлений, каким-то образом меня отображать превью, потому что их там бывает очень много, их потом не найти просто поиском, фильтра. Да, тут такое неудобство есть, там есть сортировка, но вот как это сгруппировать, пока непонятно в разных мирах, потому что у меня скромный проект, который архитектором непосредственно, он имел несколько сотен представлений, только представление модели были гораздо меньше. Супер. Ваня, спасибо тебе большое за твой коммент. Я предлагаю вам... спасибо. Три вопроса. Давайте по ним погоним. Есть вопрос очень хороший. Ты показывал много про Java, и в целом Structurizr написан на Java. Тут ребята интересуются, что по поводу GoLang и вот по поводу других языков? А что по поводу... то есть, мы говорим о том, что у нас мы в Java-код можем строить какие-то там аннотации ещё что-то, чтобы сгенерить диаграммы. Есть ли такое для Go? В этом вопрос. Да, ну, автор сам как бы не предлагает, по-моему, но где-то я видел прямо, где-то я видел, где-то я видел плагин, который позволяет Structurizr... Ну, вот есть библиотека, которая генерит C4-диаграммы из GoLang-кода. Где-то, где-то я прямо натыкался даже здесь в официальном GitHub на какой-то extension, который там тоже... Ну, понятно, да, то есть, из того, что это инструмент, то многие могут спокойно пойти и допилить скроем свой плагин написать. Это очень здорово. Да, ещё такой более глобальный вопрос: насколько распространена модель C4? Слышал, что Spotify использует. Кто ещё в индустрии пользуется? Уши. Сложно сказать, не могу ответить, не знаю. Но как бы, кто пользуется, не знаю, но вот сам автор ещё где-то там на довольно многих конференциях об этом рассказывает, поэтому популярность набирает. Даже посмотреть на проекты на эти, на GitHub, и появляется, и активно. То есть, как бы, развитие есть, видимо, там использование есть. Если вы там взять там, не знаю, White, например, или там ADCS, или там я, а и 6 нет. Странно, было много, вот 185 закрытых. Я тебя понял. Интересно. Здесь чего хорошо, что автор как бы отвечает. Вот у меня там был вопрос, как... Как, кстати говоря, скрыть, скрыть вот эти вот компоненты с диаграммой систем-контекст. Я нашёл выше, там кто-то спрашивал, и вот к этому решению они пришли, да, как скрыть. Вот это я придумал сам, как сделать тегами неудобно. Написал, собственно, issue, и вот автор ответил, что можно вот так. И это классно, то есть, активно отвечает. Спасибо, спасибо на вопрос. Ещё следующий, ещё два вопроса. Вот ещё вопрос по поводу: можно ли использовать C4 для описания процессов? Например, используется команда для регистрации, и хочется проследить некоторые процессы, которые внутри неё крутятся. Ну, я бы, наверное, сказал, что в общем случае не стоит. Всё-таки процессные методологии – они другие. Это методология для описания как бы системы и взаимосвязей. Для процессной методологии это BPM, например, есть. Да, можно попробовать взять вот, не знаю, диаграмм. Здесь показан процесс началом – это что-то согните, кто-то передаём, что-то отдаём и возвращают также ответ. В общем и целом, процесс здесь выглядит довольно просто, и инструментарий очень... Я тебя понял, спасибо. Ну, мне кажется, у команды как раз-таки есть отдельный инструмент, это называется Copilot, и там как раз-таки можно смотреть процессы и как все процессы идут. И последний вопрос, но он такой довольно-таки очень важный. Проверьте, он предоставляет ли Structurizr какой-нибудь версии для диаграмм? А, собственно, нет. А зачем? Мы, поскольку это простой текстовый файлик, мы можем его запушить в какой-нибудь Git-репозиторий, и всё. И там вести версиями. Пишет о том, что по идее всегда есть несколько утверждённых версий схем и несколько версий схем в работе. Вот это вопрос с YouTube. Но, но, слушай, к... также как и в любом программном продукте, есть несколько версий, ещё 25000 в работе. То есть, там есть версия в проде, есть версия в деве, где какие-то фичи вмержены, да. Есть ещё там куча фич, которые разрабатываются. Я как бы лучше... Лучше Git пока ничего не придумали, да, для контроля версий. Поэтому точно так же можно навесить какие-то теги, там ветки сделать отдельно. Текст позволяет детей уже как угодно. Я тебя понял. Супер, спасибо большое. Ты ответил на все вопросы. Доклад просто невероятный. Ты и правда меня удивил. Ребята, я видел другую версию доклада, и что тот был, и что этот – просто пушка. Очень крутые. Я решил добраться до on-premise, всё-таки как бы мы не говорили тогда про Java, потому что с лаймом она не работает. Здесь удалось его посмотреть, да, и всё-таки понять, в чём смысл Java. И тут тебе ещё пишут: "Спасибо, было интересно и в Zoom, и на YouTube". Да, было очень классно. Давайте поблагодарим Сашу. Да, спасибо, спасибо за внимание. Ещё предлагаю по старой доброй традиции сделать совместную фотографию с приглашённым гостем. Кто с нами в Zoom, не стесняйтесь, включайте камеры, будет очень приятно вас видеть. Можно взять кружку, кошку, ручку, есть блокнотик. Троллим, и мы такие, типа: "Ничего лучше вот этой штуки у меня нет". Крутяк. Ещё раз спасибо тебе большое. Тоже всем, кто участвовал в обсуждении, тоже хочется сказать большое спасибо. Спасибо, давали вопросы, было невероятно классно, интересно. Вот, спасибо за внимание. Да, ещё услышимся, увидимся. Всем хорошего вечера.