Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин

Итак, у нас с вами доклад. Последний в нашем зале, но, возможно, на английском языке. Говорят, последний, но не менее важный. Итак, я хочу передать слово Кириллу Витченкину из СберМаркета. Название доклада называется "Архитектурный репозиторий на базе GitLab и C4 Model для большой компании". Кирилл, передаю тебе слово.

Окей, спасибо. Да, всем привет. Меня зовут Кирилл. Я работаю в СберМаркете архитектором, и я хочу вам сегодня рассказать про то, как мы построили архитектурный репозиторий на Open Source, на простых технологиях. И одна из целей данного внедрения была в том, чтобы порог вхождения для актуализации архитектуры был весьма низким. То есть, они используют какие-то сложные системы, чтобы любой разработчик или команда могла также внести свою лепту и что-то актуализировать, потому что зачастую это является большой проблемой.

Давайте немножко цифр. Да, чтобы понимали. Да, что про размер, про проблемы, которые стоят в компании СберМаркет. Это 600+ IT-специалистов, то есть там уже к 700 близится. Но где-то посерединке — это около 80 продуктовых команд. Это более 100 микросервисов, то есть в большой компании применена микросервисная архитектура, и ее нужно уметь контролировать. Потому что если ее не контролировать, то есть очень много проблем, которые можно словить.

Давайте посмотрим на проблемы роста больших компаний. Да, то есть, когда у вас компания маленькая, вам не нужны никакие стандарты. Возможно, вам нужна какая-то карта контекстов, вы на кухне встретились, пообщались, и все замечательно. Когда компания начинает расти, СберМаркет — это именно та компания, которая начала расти. Там два года назад это было 100 человек, сейчас уже 600 специалистов, в 6 раз. Если же никак не управлять архитектурой, никак не валидировать этот процесс, то можно получить много-много проблем. И, к примеру, как отсутствие стандартов. Да, если мы договоримся, то их не будет. Это неконтролируемый рост количества микросервисов. Любая команда, как вы знаете, почему бы и новые не сделать? Почему бы еще два не сделать и так далее. В какой-то момент мы можем коснуться, у нас будет 3000. Что мы будем с этим делать? Зачастую не все разработчики понимают, как выделять новый микросервис, по каким принципам, где его границы, где его размеры и прочее. Здесь, естественно, тоже должна быть какая-то экспертиза, какой-то ревью, какой-то контроль и прочее. И, как следствие, если процесс не внедрить контроля, то и никакой архитектурной схемы, никакой карты контекстов, никакой даже простой документации просто не появится, потому что кто-то ее будет вести, кто-то не будет вести и так далее. Поэтому этот процесс обязательно нужно внедрять.

И как раз здесь показан пример такой шуточный. Да, что нам нужно посчитать сумму чисел. Разработчик думает: "А почему бы нам не создать?". И так, собственно, и появляются в компаниях 3000 микросервисов. И многие крупные компании, которые вы все знаете, которые внедряли данный подход в 12-13 годах, да, когда еще не было такого понимания, которое сейчас у нас есть, они наступили на эти грабли. Да, и, как видите, топология их взаимодействия сервисов — это фактически напоминает очень сильно такой некий распределенный монолит. Многие узлы связаны со всеми другими многими узлами, и не видно в ней какой-то слабой связности между компонентами.

И недавно, где-то полгода назад, вы наверняка читали, была статья Uber, где они публично заявили, да, что это проблемы. Вот отрывок из статьи: "Чтобы создать простую функцию, инженеры часто приходится работать с несколькими сервисами, каждый из которых лежит разным людям, разным командам. Это требует обширного сотрудничества, затрат времени на встречи, на проектирование, на проверку, на миграцию в разных сервисах". То есть, тем самым Uber явно признал проблему, что если делать сервисы слишком маленькими, если не выделять по принципу Domain-Driven Design, то вы получите просто распиленный монолит. И вот они с этим столкнулись.

Ну, их выход, да, лечение, которое для себя придумали, это группировать вот эти слишком маленькие сервисы в некие логические модули, некие такие логические контуры, фактически по принципу, наверно, Domain-Driven Design. Это делает, но мы-то сейчас, да, там год назад внедряли, и мы уже на этих ошибках можем научиться, можем не повторять ошибки, которые сделали другие крупные гиганты. И для того, чтобы не оказаться в ту самую ситуацию через шесть лет. И, соответственно, мы поняли, да, что нужно этот процесс контролировать, чтобы не прийти вот в эту же ситуацию, в эту же проблему, которую попал Uber. И поняли, что нужно контролировать архитектуру. Да, как ее часто бывают. Да, там, кто-то использует профессиональные средства больших-больших компаниях, там, где есть серьезные архитекторы и прочее, прочее. Но поскольку был определенный рост, то, естественно, используются какие-то простые инструменты. Да, это такие, как Miro, Confluence. В целом, там можно рисовать, видео рисовать определенные схемы, показывать, как разные компоненты друг с другом взаимодействуют. Но какие проблемы тут есть? Да, то есть это можно считать схемы, но отсутствие деноминации. То есть разные, разные команды, разные могут рисовать по-разному. Сложно контролировать. То есть кто-то что-то нарисовал, что это значит? Что мы это приняли, либо что-то просто нарисовали? То есть непонятно процесс принятия изменений. А отсутствие версионирования. То есть, что есть текущая версия, что есть версия, куда мы идем. Ну и, соответственно, неструктурированное хранение. Да, то есть что-то может потеряться, кто-то что-то может удалить. То есть общая структура, в которой мы зашли, все посмотрели. Здесь нет. В этих инструментах есть такие проблемы. Но зато рядовым командам достаточно просто прийти сюда, что-то исправить.

А можно использовать более профессиональные инструменты. Да, такие как... Но здесь другая проблема, что это все-таки высокий порог вхождения. То есть только специальные люди, архитекторы могут здесь что-то менять. Команда, когда что-то у себя поменяла, она не мотивирована, чтобы пойти какую-то стрелочку нарисовать. Поэтому зачастую здесь бывает такое, что реальность разъезжается с моделью. В модели нарисованы все красиво, реальность совсем другая. И последнее, что это не код. Да, то есть мы рисуем все-таки в каком-то визуальном редакторе, и это не является кодом. Соответственно, использовать, да, какой-то интерпретацию данной схемы и как ты развиваешься, во что-то интерпретировать уже становится сложнее. С кодом все гораздо проще. Да, из кода мы можем создать документацию, схему, контракты, какие-то сгенерировать, много чего мы из кода можем сделать. И в целом, вся тенденция современного мира, она двигается к тому, что "все это код". Мы тоже подумали об этом, что "все это код" — это неплохая идея для того, чтобы считать архитектуру тоже кодом. И сейчас вам перечислю, да, какие идеи были изначально, откуда брали вдохновение для того, чтобы сделать именно решение.

И начали мы с того, что DevOps. Да, DevOps весьма популярен последние там 7 лет, и в нем "все это код". Да, то есть обратите внимание: приложение — это код, тесты — это код, инфраструктура — тоже код, план — тоже код. То есть все может быть кодом. И здесь пришла идея: да, почему бы наша схема, которую мы рисуем, не могут быть кодом? И, собственно, отсюда все пошло.

Что на самом деле, да, действительно есть огромное количество решений, которые позволяют вам из кода дописывать схемы. Такие, как PlantUML, например. Мы здесь видим, да, что мы пишем четыре строки, получаем вот такую диаграмму. И фактически все диаграммы в UML вы можете нарисовать с помощью кода. Там даже есть различные циклы, функции и прочее, прочее. Это может даже на некий такой, некоторые даже компиляцию в какой-то схемами. Но идею можно продолжать дальше. Да, то есть здесь мы показали, что из кода можно рисовать простой UML. Но есть следующее, скажем так, аннотация C4 Model, который позиционирует себя как простая, но при этом достаточно аннотация для того, чтобы любой разработчик, архитектор, да, кто угодно, мог бы описать свое решение. И для этого тоже есть решение в виде отрисовки таких схем с помощью кода. Мы видим здесь слева пример, да, где у нас есть bounded context, внутри него есть контейнер, его база данных, другой контейнер, и внизу описаны связи. На выходе мы получаем вот такую схему. То есть она могла бы быть еще более обширной, но здесь для простоты я показал весьма простую. Таким образом, на взаимоотношения компонентов в рамках системы мы тоже можем описывать с помощью кода.

Но недостаточно же просто нарисовать схемы. Да, нужно еще сделать некое обоснование, почему, для чего, показать таблицу категорию сервиса, в каком категории находится, критично, не критично и прочее. Здесь мы решили, что не нужно где-то описание в одном месте хранить, схему в другом. Да, все на месте. Поскольку это все код, то Markdown, который всем просто понятен, все его знают, он прекрасно решает эту задачу. Поэтому, когда он должен как средство именно описания.

Поскольку мы поняли, да, что все можно описывать кодом, да, то, наверное, с кодом нужно работать в тех средствах, которые для этого лучше всего подходят. Да, и подхода к ветвлению кода. Здесь нужно выбрать тот, который лучше подходит. Мы выбрали Git, он самый популярный, и Trunk-Based Development как подход. Соответственно, что здесь происходит? Есть основная ветка на Main или Trunk. Нотация TBD. Там лежит фактически последняя актуальная версия. Далее, если кто-то хочет внести изменения, допустим, какой-то архитектор начинает делать решение, он бранчится от мастера, начинает описывать. Хорошо, дальше поговорим. Это шаблон, который он использует, он его заполняет, отрисовывает те схемы, которые мы только что проговорили. И вот здесь есть такая точка. Да, то есть не просто поменял и залил в мастер. Да, есть процесс ревью. Мы тоже чуть дальше будем говорить. То есть, вначале я ставил тезис, что мы хотим контролировать изменения, поэтому перед тем, как что-то будет изменено, это изменение смотрят большое количество людей. Но при этом достаточно, если все окей, да, фактически основная ветка актуализирована, и мы продолжаем дальше. Если не окей, то здесь мы, соответственно, пишем комментарии, что здесь мы не согласны, здесь не согласны, тут так не должно быть, это небезопасно. И, соответственно, человек либо исправляет это, либо вообще в целом ответ отклоняется, никакого изменения не происходит.

Поскольку с кодом, да, логично работать из Git, здесь на весь код и прочее, они прекрасно поддерживают описание архитектурных стен с помощью кода. Здесь мы видим репозиторий, его структуру. Здесь мы видим, собственно, исходный код для этой модели. Человек может здесь добавить новую связь, сделать новый коммит, сделать и, соответственно, дать. Поэтому все точно так же, как с кодом. Получить новую последнюю версию может точно так же, с помощью скачав просто. Этим вдохновлялись.

Давайте посмотрим на решение, которое здесь у нас получилось. Да, то есть за основу была взята идея "все это код". Да, и работа с кодом в определенных системах. Сначала посмотрим на структуру репозитория. Если смотреть на саму C4 Model, то автор мне закладывал, что его вдохновлял Google Maps. То есть он сказал, что я хочу смотреть сначала на планету, потом я смотрю на континент, потом смотрю на страну, потом на город. Ну и потом я могу еще больше сделать зум, и уже там вплоть до дороги рассмотреть, что здесь находится. А архитектурная схема, соответственно, диаграммы, он предложил делать также. То есть сначала смотрим на всю компанию, потом смотрим более глубоко, допустим, на департамент, потом на систему в департаменте, потом на компоненты, из которых она состоит, и потом мы можем опуститься уже до частей какого-то компонента, и потом вплоть до классов. Вопрос, да, насколько вам детально нужно посмотреть. То есть такой зум сверху вниз. И соответственно, здесь мы стали реализовывать все то же самое. Мы чуть позже увидим.

Вторая вещь, которая тоже была учтена, это стратегические паттерны DDD, такие как деление по субдоменам. Да, то есть вся компания — это один бизнес-домен. Да, мы делаем один большой бизнес. Но внутри есть много некоторых таких под-областей, на каждой из которых делает свой вклад, тем самым формирует ценность всей компании. Да, они называются субдомены, ну, либо какие-то бизнес-подобности, если говорить по-русски. И как здесь в этой картинке, это пример. Да, мы видим, что субдоменами являются там привлечение продукта, оплата, карта, кредиты и прочее. Все вместе они, видимо, судя по вот этой картинке, образуют какой-то банк. Поэтому мы стали выделять эти субдомены внутри компании, пытаться их идентифицировать, и они нам и образовали, собственно, структуры этого репозитория. То есть весь репозиторий — это вся компания. Она состоит из доменов. Такие вот мы внедрили такой подход. Это как бы очень крупные группы субдоменов, потому что субдоменов много получилось, их нужно тоже как-то группировать. Это домены: примеры рекламные, B2B, контент, взаимодействие с физлицами, реклама, работа с ритейлерами и прочее. А каждый из них, если его развернуть, он состоит из более мелких субдоменов. Здесь мы видим, это доставка, финансовые расчеты, найм и прочее. Каждый из них весьма обособлен. Да, то есть это такой маленький, подобный бизнес. Внутри субдомена находится команда. То есть они как бы там работают, их может быть там три-четыре, пять штук, по-разному. И у каждой команды есть сервис для того, чтобы реализовать подход. Да, у каждого сервиса должен быть владелец. Получается, вот такая вот матрешка, где мы можем с самого верхнего уровня опускаться ниже, ниже, вплоть до сервиса. При желании снизу наоборот подняться на самый верх и понять, в каком домене, в каком домене наш сервис дает какое-то нам преимущество. И поэтому структура репозитория, да, соответствует структуре организации. Это важный момент. Есть команда переходит в другой домен, другой субдомен, то, соответственно, репозиторий я просто переношу в другую папку. Если появляется новый субдомен, то появляется новая папка. Если наоборот, он пропадает, папка пропадает. Ну и так далее. То есть все организационные изменения отражаются в истории за счет применения папок. Это достаточно просто передача сервисов между командами, если такое все-таки возникает, делается по тому же принципу, просто сервис из одной папки перекладывается в другую папку, тем самым подтверждается, что теперь владеет другая команда.

И вот эта матрешка, про которую рассказывал, тут самый зум, про который автор C4 говорил. Вот здесь он и показан. Здесь первое, да, это основная страница этого репозитория, где мы видим вообще, из каких доменов состоит компания. То есть мы видим их взаимоотношения, мы видим, кто является клиентами и прочее, прочее, прочее. Окей, мы можем любой из них кликнуть. Да, то есть фишка в чем, до что из кода мы можем генерить как картинку, так и HTML-страницу. Поэтому там можно добавлять ссылки, и можно, естественно, кликать на разные компоненты и попадать внутрь. И так далее. И, допустим, мы кликаем с вами на Operations domain, вот этот, и мы попадаем внутри него. Здесь, в силу того, что вот этот зум он очень многоэтапный, сделали так, что мы смотрим из наружу изнутри наружу и снаружи внутрь. Здесь написано, что дома — это мы смотрим изнутри наружу, то есть мы показываем, кто является потребителем этого домена, так какие другие домены являются клиентами, какие интересанты являются его тоже потребителями и так далее. Теперь мы можем посмотреть: окей, внутри. И вот здесь мы уже видим разбивку домена по субдоменам. То есть какие субдомены находятся внутри домена Operations. И здесь показаны их связи. Да, то есть какие у нас есть роли, нас какими доменами взаимодействуют, их обслуживают, когда они друг с другом связаны, домен связан. И здесь есть контур, добираемся, тем самым показываем, что домен находится. Далее, да, мы можем провалиться дальше. Да, мы можем Watch robs, к примеру, провалиться. На самом деле, можно проваливаться абсолютно в любые. Да, но мы вот идем по такой вот степени. То есть можно как вниз, так и вверх. Вы можете серфить в любую сторону. Проваливаемся еще глубже. Watch robs. Здесь мы видим уже более техническую схему. Да, то есть из каких сервисов и систем состоит этот субдомен. То есть какие там системы задействованы, чтобы он выполнял свою функцию. Понимаете, что это автоматизация процесса найма. И здесь мы видим, да, какие у нас есть фронтовые клиенты, какие у нас есть китовые, какие у нас есть микросервисы, которые это все обслуживают. Да, и как они друг другу связаны. Каким образом есть какие-то внешние системы, которые потребляют результат работы сервисов. То есть мы провалились еще ниже. Естественно, здесь мы можем проваливаться в каждый из этих, как бы, контейнеров еще более на низкий уровень. Поэтому давайте еще провалимся внутрь сервиса. Здесь мы проваливаемся внутрь сервиса. Здесь мы уже видим детализацию вплоть до базы данных. Надо понимание, какой вендор баз данных у данного сервиса, какие у него взаимодействия с другими системами и прочее, прочее, прочее. Здесь показана такая весьма простой сервис, чтобы экран не загружать. Каких-то более сложных сервисах у них там побольше всяких связей, побольше коммуникаций, схемка такая более плотная получается. Но самое главное, что мы видим, кто является клиентом сервиса, мы видим, через какой гейтвей к нему приходит, да, через какое, какие приложения он обслуживает, какая у него база данных, да, и с кем у него межсервисная интеграция.

Но какая здесь возникла проблема? Да, что вроде бы вот это вот иерархия матрешкой и то, что все команды в компании могут вносить свой вклад в общий вот этот архитектурный репозиторий, естественно, проходя превью опытных архитекторов. Но проблема возникла в том, что многие компоненты, да, к примеру, как акторы, либо какие-то сервисы, их именовали схоже. Да, то есть было понимание, что это один и тот же самый актор. Оно по-разному. То есть можно сказать, клиент, покупатель, клайн, юзер — да, это все как бы про человека, который что-то у нас хочет приобрести. Но из-за того, что его именовали по-разному, священника, будто это абсолютно разные. И здесь появилась идея создать единый отдельный репозиторий со всеми компонентами, которые участвуют в системе. Да, то есть завести всех акторов, свести все сервисы, завести все это, завести все мобильные приложения, чтобы команды уже могли потом из них конструировать схемы. Поэтому создали отдельный репозиторий, в который сложили абсолютно всех. Идентифицировали, нашли всех векторов, все сервисы, все монолиты, вся кита. Вот это все и сделали хорошее, понятное, нормальное описание. То есть инвестиция в описание качества здесь были гораздо больше, чем то, когда это команды начали делать, потому что им нужно было писать каждый контейнер, это занимало времени, поэтому описания были не очень качественные. Здесь же можно хорошенько подумать, даже сходить людям, которые работают с некоторыми либо сами являются акторами, спросить, чем ты занимаешься. Тем самым начал даст развернутое описание. И этого вектора можно написать уже очень [музыка] качественное, корректное. И люди, которые рисуют схемы, они не могут менять описание, они не могут добавлять новых контейнеры, делают только группы людей, как раз те, которые проводят ревью. Из чего-то не хватает, то, соответственно, они добавляют. И здесь мы как раз с вами видим, да, что у нас есть группа акторов, да, по принципу один актор — один файл. То есть один контейнер — один файл. И здесь мы видим, что внутри него находится пикер, сборщик, собирает заказ. Таким образом, потом, когда мы делаем какую-то схему, например, как здесь, это не просто все перечислены с целью просто, чтобы не отображались, мы получаем отображение всех, которые можно использовать. Окей, все вот такие вот компоненты завели в этот отдельный репозиторий. И теперь мы можем за счет вот такого инклуда вставлять их в, собственно, в любую схему. Да, то есть достаточно подключить вот такие вот шесть строк. Да, мы здесь видим, это мобильный веб G2. Добавляю их. Можно теперь очень легко и просто строить схемы. Не нужно вводить никакого описания, достаточно просто выбрать всех участников. Да, и потом между ними связь настроить. Мы здесь видим, что мы взяли Питера — это сборщик, мы взяли приложение, и потом сделали связь, что пикер использует приложение. Тем самым, да, вот эти три строчки кода позволили нам сделать вот такую, в данном случае, простую схему. Да, но для дома она самая уже описание приехало, уже технология приехала, нормальное название. И то же самое с человеком. Таким образом, избавили команду от придумывания названий. И тем самым себя избавили от того, что команда использует систему или контейнер, который просто не существует. То есть не могут работать с существующими компонентами.

Окей, вспомним нашу первоначальную цель. Да, мы хотели контролировать появление новых сервисов, развитие архитектуры, развитие системы. И здесь мы подходим как раз к теме ADR. Да, то есть структура архитектурного решения. То есть что мы рассматриваем на ревью, что команда должна принести, чтобы доказать нам, что действительно этот сервис имеет место быть. Здесь есть разветвление, что я может быть двух видов. Это либо когда появляется какая-то новая компонент, новый сервис в системе, либо это change, когда уже существующее нужно сделать только какое-то изменение, добавить новую интеграцию, либо наоборот ее брать. То есть какая-то актуализация. И здесь мы помним, да, что мы храним все в репозитории, в GitLab, в мастер-ветке. Поэтому, если нужно что-то новое сделать, то это выглядит как бранч, в который используется шаблон, шаблон заполняется, и потом, собственно, новая папочка появляется в этом репозитории. И ADR, да, нет, делается при появлении сервиса, системы, приложения. Здесь такая структура, что сервиса либо системе, что это вообще такое. Далее, то есть некоторые пояснения, почему эта система вообще должна появиться. И набор диаграмм, который описывает данную систему. Да, такая контейнерная, компонентная. И здесь есть некоторое деление на те файлы, которые будут добавляться, а те, которые не будут, никогда добавляться не будут, только изменяться. Как вы видите, что вот эта синяя структура, то, что здесь синим показано, да, там диаграмма сами сервиса, они просто создаются впервые, и потом, если происходит какое-то изменение, то они просто изменяются. А внутри папки ADR здесь идет наоборот накопление, что сначала нет, потом change, потом change 2, через 4 и так далее. То есть на каждый появляется новый файл. И таким образом, вот эти ADR они являются неким пояснением к тому, почему мы поменяли эти схемы. Сами схемы они только изменяются, новых они не появляются. И здесь, соответственно, у нас раскроем, да, разделы, где что пишется. В контейнерной диаграмме мы раскрываем, как у нас взаимодействует данный сервис с внешним миром, своей базой данных, с другими сервисами, синхронно, асинхронно, кто вызывает, через какой и так далее. Показали, как он встраивается в общую схему. Далее мы можем показать, что у него внутри. Это является опциональной, да, эту схему можно пропустить. Но тем не менее, если внутри сервиса происходит какие-то важные, критичные изменения, допустим, там делается какой-то диспетчеризация, какой-то сложный алгоритм и прочее, обладает какой-то сложной доменной логикой, то тоже команда может показать, что здесь есть разные слои, да, там слои API, слои Application, слой домена и так далее. Но это опционально, если это требует необходимости. Если нет, то нет. И одни диаграмм, то есть диаграмма того, как у нас хранятся данные. Да, бывают системы, в которых очень много данных, связи с этим, да, на это тоже обращает внимание. В основном люди, которые систему будут поддерживать. Мы, когда дойдем до ревью, да, вы увидите, кто это ревью делает. Да, то есть это делает не только архитекторы, это делают еще люди, которые занимаются обслуживанием этой сервисов. Да, то есть команда хочет создать сервис, которым явно что-то странное, да, в базе данных, его невозможно будет обслуживать. Данная схема как раз подскажет, что здесь что-то не так. То есть мы смотрим на любой сервис, любую систему, исходя из того, что у него есть, конечно, набор того, что он может делать. Да, то есть у меня есть конкретический набор юзкейсов. Да, я могу дать. То, естественно, здесь имеет смысл раскрыть, что данный сервис будет реализовывать, какие у него возможности. И диаграмма раскрывает возможности сервиса. Далее, каждый из них, да, мы можем, при желании, раскрыть уже в sequence диаграмм. То есть показать, допустим, получить все виды товаров. То есть кто будет вызывать, как будет вызывать, будет ли эта система вызывать другую систему, если да, то как. И здесь уже можно как раз предварительно договориться в неких набросках на те контракты, которые могут быть между разными системами. Здесь пример видим, что какой метод мы вызываем, что мы получаем. И то есть мы с вами фактически с уровня компании спустились до уровня sequence диаграмм. Да, то есть и так можно сделать по любому сервису.

И теперь посмотрим на вот эту секцию, как раз, которая сказал, где добавляются, собственно, вот эти вот ADR. Первоначально, ты нет, система появилась. Что здесь есть? Здесь всего три раздела. Здесь мы боролись за достаточность, но при этом определенную простоту. То есть какие-то схемы мы вынесли сюда. То есть они здесь. Здесь у нас такое, а-ля пояснение. Эти схемы нарисовал. Почему они имеют место быть, почему это вообще должно существовать. Сверху ссылки на бизнес-требования. Здесь проблема, какую проблему вообще решаю. Если это проблема, потому что она бывает так, что проблемы нет, просто хочется создать. Такое, к сожалению, бывает. Поэтому это сразу же, естественно, отсекается. Окей, допустим, проблемы есть. Далее, мы очень активно используем это основной подход для понимания, для чего вообще должен быть разрисован процесс. Понимаем, где какие-то пограничные события. Поднимаем, где граница контекста. И вот граница контекста и вырисовывает для нас границы сервиса. Поэтому, если команда не проработала наш торрент, значит...

Она просто от балды решила создать этот сервис, поэтому здесь обязательный пункт. И в итоге решение, в котором люди пишут, что соответствует: "Мы решили создать такой-то сервис, который будет так настраиваться в систему". Это некий такой расширенный, по сути, коммит к их изменению. Окей, это все сделали, да, и наступает архивил, то есть они закомитили свою ветку. Теперь нужно это сделать merge request и отправить его на ревью. Да, у нас называется Arch review, где группа людей, до от каждого домена, до по одному такому, скажем так, архитектору, шесть человек, плюс безопасность, плюс те, кто это поддерживает с разных сторон, рассматривает вот это решение. И здесь мы боремся за что? За чтобы у нас было сильно зацепление, слабо и связи. Название: "Ошибка". Да, чтобы здесь у нас было, собственно, вот этот верхний подход, да, где у нас внутри сервиса сильно зацепление, да, между ними была слабая связность, а не вот так вот, как показано здесь снизу. То есть тем самым, да, если мы будем делать нашу систему, как показано снизу, то мы получим распределенную налить, потому что, как видите, вся сложность, она находится между двумя, как бы, системами. Сверху же все наоборот, да, все сложность находится внутри, и между ними слабая связь. Поэтому вот как находится сверху, так мы хотим. И вспомним, да, наш вот этот изначальный тезис, да, что как мы не хотим здесь, ребята, явно не получилось вот таким вот образом, да, как вот здесь заявляется. И мы всеми силами стараемся сбежать именно вот добиваться того, что система получалась вот такое. И поскольку мы все схемы и описания своим входе, то работаем с ним как с кодом. На то есть команда, как говорил ранчо, и ветку, она это делать вместе со своим архитектором, который находится в рамках и домена. Он их как бы ассистирует им, он понимает бизнес, он понимает их проблема, но при этом обладает всеми знаниями для того, чтобы действительно строить слабо связанная система. То есть речь не идет о том, что команда взяла и что-то запретила, она работает в рамках вместе со своим архитектором, в рамках стране сидят где-то слова башня сверху, они распределены по доменам, они вместе с ним готовят решения, которые мы с вами проговаривали, и затем уже отправляют его на ревью. Саму ревью тоже автоматизировано в GitLab, это позволяет прекрасно делать. Да, мы здесь видим, что нужно получить 5 опробовав от став инженеров. Устав инженер этот как раз есть тот самый архитектор в домене, то есть суперсинер инженер с архитектурным, скажем так, скиллами. Security нужно получить два, и это платформа. Но это, по сути, администратора тоже два. И когда решение набирает все обрывы, то появляются кнопками. То есть если вся про нажали, то можно мяжить. Да, пока что межблока, потому что мне достаточно проводов. Таким образом, решение контролируется с абсолютно разных сторон: команда сама, став архитектор внутри, да, другие архитектора снаружи, да, еще Security, еще администратор. Таким образом, получается все целое такое осмотр со всех сторон. И если все хорошо, да, то мы просто мерзжем. Это значит, что все принято, репозиторий актуализирован. Если есть вопросы, то открывается треда, где идет диалог, да, то есть если все тренды закрыты, значит, можно мешать. Если диалог приводит никуда, делаем онлайн встречу. Если все совсем плохо, то просто отклоняется и, соответственно, не принимается данное решение. Далее, приняли, поработали, прошло два месяца, теперь нам нужно сделать change, то есть что-то поменялось. И здесь опять же таки, в чем связь, что администраторы не откроют вам не новую интеграцию, если ее нет на схеме. То есть просто не будем открывать, потому что. И таким образом образуются некоторые связи, что команда заинтересована в том, чтобы актуализировать репозиторий, она делает Change. И здесь у нас как раз просто меняются те схемы, которые уже были, добавляются новые стрелки, либо убираются, добавляется новое описание, как новый файл change, где описывается, почему мы так сделали. И таким образом, да, описание становится достаточно более простым. Да, только проблема решением, что именно здесь уже не нужен, то что можно было. И также дополняется схемой, да, в котором красным показан, что мы добавили интеграцию, вот он такой, это находится файле, да, то есть в файле показано, что поменяно, а в самой схеме просто меняется, актуализируется схема. И опять же таки, через принятие этого мерча квеста мы актуализируем репозиторий. Итого, да, что мы получили, да, то есть мы имеем реально контроль на запуском, условно, не один, пока команда не прошла этим самым вот это вот, давайте-ка создадим сервис, который складывает два числа, уже не получится. Актуальная архитектура, документация большой эти системы, да, то есть за счет такого процесса, что появление каждого нового сервиса или какого-то компонента требует формирования того набора артефактов, которые вам показывал, наполняет это репозиторий, делает его актуально. Если нужна новая интеграция, то естественно люди обращают внимание на схемы, которые эти интеграции открывают. Опять же таки, это приводит к тому, что сначала нужно сделать челлендж, и только потом эту операцию будет получше. За счет применения вот таких вот подходов, которые близки командам, да, такие как битва си 4 модуль, который позиционируется, как скажем так, рисование архитектурных схем для разработчиков, айды ешек, в которых это можно делать, да, то порог входа достаточно низкий, да, вам не нужно изучать сложные нотации, там типа архимейта и прочее моменты. Администратор открывает доступ, соответственно, схема. Мы тоже проговорили, и все сервисы учтены, и связи понятны. То есть изначально, пока этого репозитория не было, просто было непонятно, какие системы вообще существуют. После его появления здесь четко можно их посчитать. И поскольку это код, дата посчитать это можно абсолютно любыми способами, можно его интерпретировать, можно его парсить, можно сверху какой-то фреймворк написать, да, то есть над кодом мы можем делать очень многие вещи, в отличие от каких-то просто схем, которые дает нам очень много расширений. Единая аннотация, шаблон. То есть поскольку есть review, есть шаблон, который я вам показывал, есть нотация единая, это 4 + ML, то уже каких-то вариаций, да, что все рисуют по-разному, уже нету. И контроль изменения через год review. То есть действительно контроль. То есть просто так что-то изменить и замёрзнет ни у кого не получается. Планы, да, то есть поскольку это такой, ну, скажем, не старта, промежуточный этап, естественно, это всего есть развитие. Естественно, после внедрения этого появилось много идей, проблем, которые хотелось бы тоже автоматизировать. И то, что все базируется на коде, дает огромное преимущество. Из него можно интерпретировать во что угодно. Да, хотите документацию делать, хотите веб-сайт сгенерируйте, хотите визуальные схема Нарисуйте, хотите какие-то, не знаю, конфигурация Создайте и прочее, прочее, прочее. И я вам говорил, что администратора смотрят на схему для того, чтобы открыть доступ. Да, и здесь у нас появляется между системой, которая отвечает за интеграция, да, и архитектурам, появляется человек, который должен посмотреть, что-то сделать. А если вдруг потом интеграция будет удалена, он должен сделать все обратно. Это человеческий фактор, да, но здесь можно было бы это брать, потому что все это. И почему бы из Кода, да, эти после отруба новое решение теми же самыми администраторами не автоматически изменять на конфигурацию? То есть сейчас вам говорю про идею, которая будет следующим этапом. И вдохновлялись мы подходом, как где не из года, но как бы не из программного кода генерируете какой-то там контракт, вы сначала контракт определяете, потом у вас появляется генерируете какие-то сервера, конфигурации, прочие вещи. И почему бы здесь не сделать то же самое, да, то есть сказать, что схема First, да, то есть там было E5 First, тут у нас схема First. Есть на схеме появляется новая Стрелка, при интерпретации вот этого исходного кода, вот этих команд формируются некие файл, который можно применить, да, и соответственно, это интеграция реально появится. Стрелку брали в мастер-летку замерзли, то опять же таки, какой-то себе процесс актуализирует конфигурация, учитывая то, что раз я не поменялось. Таким образом, конфигурации будут соответствовать всегда схем. И вот эта извечная проблема того, что схема не соответствует реальности, она должна уйти. Пока не делаем, есть такая идея, как я уже сказал, да. Из кода можно делать очень много, поэтому здесь идеи бесконечно. И на этом у меня все. Можно перейти к вопросу. Да, спасибо за доклад, Кирилл, очень интересно. У нас на самом деле чат разрывается от вопросов, поэтому я предлагаю один вопрос в зале, один вопрос чат, и как раз успеем до начала мероприятия. Значит, первый вопрос от Екатерины. Она спрашивает: "Вопросы шли в течение доклада, поэтому вот создаю, как шли, как-то синхронизируете, связываете версию описания решения и версии, я думаю, реальных реализации?"

[музыка]

Здесь пока что, как я уже говорил, это аудит проводится. Вот, но последнее, то что идея вот сейчас в эту сторону движемся, чтобы схема, схема First, да, то есть чтобы схема конфигурации менялась, конфигурации, схема, и схема, конфигурации менялась. В принципе, это сделать с точки зрения техники достаточно легко. Адреса в каждом контейнере прописать их хосты, связи. Это значит, два хоста связывается на схеме, мы подтвердили, значит, у нас такой-то дырку надо пробивать между двумя этими хвостами. Пока это на уровне следующего этапа. Спасибо большое. Следующий вопрос из зала. Вас не слышно. Включите микрофон, пожалуйста, или помогите, пожалуйста, включить микрофон. Да, буквально два числа. Вот количество мерже архитектуры в месяц и дней на рассмотрение одного мерзля. А в месяц около 20, наверное. Вот сейчас еще правда актуализация идет, то есть какого-то тех долго, да, то что раньше не было заведено, поэтому там их больше. Но около 20 мерже в месяц. И SL у нас два дня. Мы берем два дня как среднее время для того, чтобы не задерживать, потому что здесь важна борьба за time to market, когда если что-то простаивает, значит, мы разработаем сильно дольше. Поэтому обычно у нас два дня SL. Через два дня у нас уже лампочка загорается. А подскажите, пожалуйста, насколько я понял, даже несмотря на то, что вот схема это код, из реального кода схемы вы пока никак не генерите. Это все ручные труд затраты. А смотрите, Исхода схема генерировать мы не планируем. Как я приводил аналог с идеей Open API, да, то есть я параллель просто проведу, да, мы можем из кода генерить, но тенденция сейчас наоборот. Мы должны свагер генерить, потому что контракты в первую очередь. Есть все то же самое. Мы не хотим схемы из кода генерировать. Мы хотим из схем генерировать те интеграции, которые на схеме отражены между компаниями, чтобы дала в первую очередь, а во вторую очередь уже конфигурация, которая из нее появляются. Иначе просто будет какая-то будет вибрация, создают и появится какая-то кривая схема. Мы бы хотели бы на схеме видеть, как должно быть, из этого конфигурации генерировать. Ну и на текущий момент вы все-таки административным путем решаете разъезжание там схемы с жизнью? То есть вы начали с того, что схема в архимейте у разработчика нет лишнего стимула стрелочку нарисовать и закончили тем, что у вас такая же проблема. Пока вы не заставите, это никто не будет это делать. И пока это все ручные. Пока что, пока что, да, пока что связь через администратора, да, то есть условно к нему приходит команда, говорит: "Мне нужна новая интеграция". Он смотрит схема, если там нет стрелки, то ничего не открывает. Но следующий шаг, который будет, это соответственно, вот который есть уже, генерировать эти конфигурация. То есть мы замерзли в Мастер, то соответственно, следующий этап пока не успели. А еще я вот смотрю на тех примеров, можно тогда Вы согласны, у нас была очередность какая-то? Так вот спрашивают: "Кирилл, как вы определяли домен?" Домена определяли из, собственно, анализа бизнеса. То есть, во-первых, и звон шторминга, да, мы проводили шторминг и пытались выделить. Второе - структура просто. То есть взяли такие два критерия: это понимание текущую структуру и Иван шторминг. Они в какой-то момент не сошлись, и мы, естественно, задали себе вопрос: "Как должно быть?" и сделали небольшой урок изменения. Вследствие этого сейчас у нас осталось буквально 11 минут. Я передаю дальше микрофон в зал. И дальше. А вот, глядя на схемы, я вот не совсем уловил. Я так понял, вы прорисовываете связность между сервисами, а именно инфраструктурную часть, там сервера и их сетевую связанность, вы там как-то отражаете и размещение серверов сервисов на серверах? Мы используем губернатор, поэтому как бы особо заморачиваться на том, каких конкретно серверах находится. Вот они где-то в Облаке находятся. Вот, но в целом тоже нотация C4, она позволяет добавить еще диаграмма, где, собственно, все это можно отразить. Здесь просто радоваться нет. Мы используем платформу как некие облака, что сервис туда попадает, где-то там живет, где нам. Спасибо большое за вопросы. Так, у нас очень много вопросов. Я надеюсь, что успеем все. Значит, вопрос: "Почему на изменение архитектуры надо создавать отдельные идеалы, а не менять существующие?" Во-первых, мы меняем просто существующий, это раз. А вот этот отдельный ADR - это пояснение, почему мы так меняем, да, то есть в чем мы так решили это поменять, да, то есть у нас там, как вы помните, было два пункта, да, это появилось новая проблема, и поэтому сделаю новое решение, и показали вот это новую интеграцию, вот. То есть это пояснение. В идеале сомах пояс. А так-то изначально они просто фиксируют диаграммы, да, и там просто новую стрелочка добавляют. Спасибо. Передаю вопрос зал. Спасибо. А еще такой вопрос: упомянули, что также используете диаграммы данных у себя в репозитории. Вот вопрос: вот эти диаграммы данных - это просто иллюстрации для каких-либо сервисов или существует, может, какой-то общий репозиторий сущности данных? Может быть, они как-то связаны у вас с интеграционными связями? То есть ваша модель, ваша репозиторий как-то имеет возможность представления архитектуры данных, отслеживание или это вам сейчас не интересно, не задумывались, может, это в планах? Пока нет, да, вот это основная с. Ну, схема, которая была показана с таблицами, да, то есть, которая есть у сервису система, она в первую очередь нужна для понимания того, будет ли на том, скажем так, на том типе баз данных, которые команда выбрала, работать то решение, которое они хотят. Потому что бывали такие случаи, что команда хочет там иметь просто космический RPS, выбирает не совсем то решение, которое для этого подходит. Это нужно было прочекать, как бы заранее. Вот. У нас, естественно, появляется понимание, где какие данные лежат. Но пока что вот именно собирать вот как вы сейчас сказали, да, то есть какой-то единый вот такой вот, как сказать, понимание, где какие сущность такого нет. Но естественно, если я просто поиском начну искать пример заказа, да, то я естественно наткнусь на эту таблицу. Мне просто поиском скажет: "Смотри, до заказа лежат в таблице заказов". Я пойду, пойму, что такая структура, такие атрибуты, так они хранят. Вот. То есть косвенно пока что можно понять. Ну, можно это развить и уже Прийти к тому решение, которое спрашивает. Насколько это код? У нас ничего не ограничивает. Спасибо. Спасибо за вопросы, за ответ. Сейчас у нас вопрос онлайн, и потом зал. Вопрос: "Архитектура как код упрощает внесение изменений разработчику, а работают ли с этим аналитики? Может быть, ты можешь поделиться?" Аналитики, аналитики нет. Тут не уточнили вопрос. Задавали, можете уточнить, пожалуйста. В целом, да, то есть то, что получается в конечном итоге, с этим работают много людей. То есть, грубо говоря, когда приходят новые системные, к примеру, ему нужно что-то с чем-то с интегрировать или что-то как-то, знаете, вот он просто серфит это репозиторий и понимает, где какие данные лежат, какой сервис за что отвечает, как команда за это отвечает, в каком-то менее и так далее. Там на самом деле еще есть понимание, кто ответственный человек найти. И таким образом он может понять, где нужно сделать изменения, чтобы решить свою проблему. Возможно, его проблема же решена. Пока этого не было, вообще было непонятно, если такое решение нет, теперь нему можно ходить для себя информацию могут использовать. Спасибо. Вопросы. Спасибо большое за доклад, очень интересно. У меня вопрос чисто прикладной, очень технический. Картинки вот эти сгенерированные из ПЛАНТА, их умеет генерировать или вы генерируете там прикормите и туда кладете? Нет, их генерирует сам GitLab. То есть есть движок, который генерирует. То есть локально на машине тоже постоянно он их перерисовывает. Вот. И GitLab тоже перерисовывает, и они там разный формат может перерисовываться, как в обычном PNG картинку отрисовывает, так и в SVG. У вас еще большой плюс, то что все будет кликабельно. Ссылки вы собственно делаете, так понимаю, ссылок. И он позволяет по ним кликать. Просто движок, что мы сейчас используем, с выигрышные ссылки блокирует. Меня вот это вот именно конструкция заинтересовала. Спасибо. Спасибо большое. Вопросы с чата. Как и где вы работаете с глоссарием? Разделы термины в ADR - это общий глоссарий по всем доменам? Доменам нет. Вследствие того, что мы с вами говорили, то что мы стараемся разбить команду, компания на субдомену. Сейчас, как мы понимаем, да, разбиение нас домена приводит нас к избиение на баланс контексте. Конечном итоге, естественно, язык, да, на котором мы общаемся в рамках отдельного контекст, он свой. Вот. Поэтому здесь глоссарий с терминами, он есть, он хранится тоже в этом репозитории, и он специфичен под каждый. Решили хранить примеры глоссарий для поэмы. Некоторые термин дублируются, но чтобы не пытаться построить единый язык для всех компания, да, мы структурировали это по, по субдомину. Каждый домен свои слова ведет, и тоже можно легко найти, чтобы разработчики докодировали, они брали название из этих терминов. Они сами придумали там клиенты, назвали там клиентом. То входит должен быть клиент. Спасибо. У меня видимо сигнал запаздывает. У меня было ощущение, что так. Передаю вопрос зал. Единственный у нас три минуты. Я не знаю, насколько в зале комфортно вам. Я думаю, лучше задать все вопросы потом, вы пойдете уже на продолжение. Вот вопрос зал: "Как вам комфортнее будет?" Добрый день, Николай Тиньков. Спасибо большое за доклад. Был очень интересно, особенно в плане того, что был себя управление используем похожий набор инструментов, похожий набор нотации. Очень круто увидеть. Ну, что ты, возможно, не ошибся, есть другие люди, которые думают также. У меня вопрос именно по процессам, а именно в плане ревью. Вы упомянули, что у вас есть SL два дня умерших квестов архитектурные территории. Как он обеспечивается? И что будет, если он продолжается? Потому что у нас это большая проблема, что архитектурное могут висеть там, словно, неделя, полторы. [музыка] А здесь, во-первых, мы это отслеживаем просто человеческим фактором. Во-вторых, у нас есть на каждое, на каждый вот этот мерши квест дополнительно заводится ticket Jira, да, где такая Kanban доска, вот, и соответственно, там колонки есть, да, то есть команда перетаскивает колоночку, что рейдзив review, соответственно, это значит, что архитектора, который за этим следят, они как бы, как каждый день приходят, они приходят на эту доску и чек. Соответственно, как только они это прочекали, они переводят типа вот. И далее, там естественно, можем собрать эти метрики, которые нам говорят, у нас перехода вот этой задачи по доске, и не должна превышать эти самые два дня. То есть еще вопрос, да? Хотите просто в очередь станьте. Так, у нас вопросы чата. Я не знаю расшифровку, к сожалению, тут две буквы и Б. Реально для выводов только схемы в гите? Я думаю, Кирилл, ты понимаешь. Ну, естественно, нет. Естественно, они проводят [музыка] как бы аудит с помощью специальных систем, которые это делают. Но фишка в том, что вот между этапом, когда что-то выводится в провод, и этапом, когда делается превью, проходит еще этап разработки. Наша задача на том этапе, когда еще разработка не началась, сразу же отсечь какие-то заведомые некорректно решение, чтобы команда три месяца не разрабатывала решение, которое потом скажут, что такое нельзя лить Production. Вот, поэтому нет, ревью на этапе, что да, тут, если так разработаете, 99 процентов все будет. Потом, естественно, когда доходит до развертывания, администратор сверяется со схемой, что они разработали действительно то, что разработали. А и бэшники, естественно, это все аудируют всеми процессами, которые. Вот, это просто такой ревью, чтобы они там, чтобы команда не разработала что-то плохое. Спасибо. У нас вопросы зала. Как раз таки, Кирилл, спасибо за доклад. Хотелось один нюанс уточнить. Вот у вас там на слайде был как раз нарисовано, что от основной ветки от пачкаются две ветки, которые находятся на изменении, и что происходит, если начинает противоречить другому? В какой момент выясняется при ревью? Так, где-то здесь было. Не суть важно. А на самом деле, такой крайне редко бывает, потому что, во-первых, вот это разбиение по этим субдоменам, до, которая показывала, но в принципе, изначально подразумевает, что у нас слабо связанность между теми, скажем так, командами, да, или подразделениями, до, которая делает какие-то изменения. То есть такой конфликт может быть только тогда, когда какие-то команды, которые сидят рядом, делают одновременно такие изменения. Но решается очень просто, что также, как в коде, то есть мы это просто, то есть мы принимаем сначала одно изменение, потом смотрим со вторым, его принимаем. Но такой ситуации на самом деле почти ни разу не было, чтобы две команды, которые по идее должны быть связаны друг с другом, вдруг редактировали какую-то одну схему. Вот, они почти всегда находятся на разных концах и редактируют какие-то свои части. Но будет, соответственно, такой же мяч, как в обычном коде. То есть мы будем смотреть на две схемы, и потом посмотрим, как они сочетаются. Во-первых, во-вторых, такая ситуация, она вследствие того, что этот процесс, скажем так, он публичный. То есть есть канал, где люди скидывают свои вот эти: "Смотрите, мой мерч, Посмотрите". И вот эта группа вот этих став инженеров, вот таких вот Архитекторов, которые находятся в доменах, они у них есть определенные осмотренность, и они вместе с командами готовят решение. Когда он готовит свое решение, с вероятностью 90 процентов он знает, что в другой команде делает что-то похожее, да, и они еще заранее договорятся о том, где что будет изменяться, и соответственно, свои схемы уже зальют в корректном виде. Но если бы просто. Спасибо. У вас вопросы из онлайна. Кажется, что вносить изменения в код сложнее, чем визуальным редакторе. Насколько это действительно так? И простите, сложно, у меня улетел вопрос. Сложно ли редактировать большие диаграммы? Да, есть определенная сложность, особенно раннем этапе. Да, конечно же, стрелочки, до проводить визуально приятнее понять. Но это на моем опыте, да, когда вот я это все рисовал, то есть спустя время, когда рука набивается, то это становится достаточно легко. Более того, достаточно интересно, что какие-то типовые блоки, которые вас в принципе всегда есть, допустим, вы говорите: "Мне нужно Новый сервис раскрыть мобильного приложения". У вас там начинается там где-то вей одно приложение, второе приложение. С кодом вы просто можете взять заранее заготовленные, как бы блок, ставить его, добавить свой сервис, у вас пол схемы будет отрисован уже сразу. Вот. Если стрелочками, то вам будет сложнее. Вам нужно будет заново все рисовать. Поэтому какие-то заранее заготовленные такие темплейты, их можно заготовить и с помощью них описывать какой-то крупную часть диаграмма, потом дорабатывать ставкой новых компонентов. За счет того, что внедрили вот эти компоненты, стало гораздо проще. То есть просто contel Control V, и мы вставляем уже там сервисы. Шаблон есть, уже сказал. Вы можете вставить некий там сразу три приложения плюс гитарой одним блоком, потому что в большинстве схем там одно и то же нужно. Вот. И это тоже ускоряет топлено на работу. Но то, что мне больше всего нравится, это то, что получается единообразно. То есть движок, который отрисовывает схемы, он всегда их рисует, ну, как программа, да, то есть он оптимальных рисует. Поэтому вы как бы в этом, на схеме вам нужно оптимизировать свои стрелочки, чтобы было красиво. Здесь же вы пишете код, а он за вас решает, так что было красиво. Поэтому здесь такие плюсы. Но вначале, да, действительно нужно руку с этим. Есть момент. Спасибо. Передаю вопрос зал. Кирилл, спасибо большое за доклад. Очень интересно. Вопрос следующий: ты говорил, что вы не принимаете идеи, рке мерч квесты, пока не проведут вент шторминг, ну и не докажут необходимость наличия того или иного сервиса. Хотел уточнить: вот ивент шторминг для таких случаев проводится какой-то как это сказать, сжатый, урезанный? Потому что обычно, да, это какой-то глобальное событие, где прям все, все собираются, менеджеры там и так далее. Как в этом случае, какой состав команды, который проводит этот? Во-первых, здесь какая история? То есть вы можете всю компанию провести, она какую-то часть в рамках департамент, в рамках департамента. Это не то, что прям какая-то архи сложная задача. Но самый важная проблема, которая есть в разработке, это когда разработчик комитет в прод не то, как надо, а то, как он понял. Да, если он понял бизнес неправильно, то заведомо прод комит баг. Вот. Поэтому понимание, как устроен бизнес, это крайне важно для понимания корректно границы микросервис. Поэтому проводятся полноценная шторминг, сервис жизненный цикл сервис - это два года и более, да, поэтому можно потратить, да, там два дня ради двух лет, чтобы его границы верно определить. Состав обычно это около 10 человек. Это технари, да, то есть Тим Лиды, сеньора, те, которые будут участвовать так или иначе. И плюс от бизнеса, бизнеса кто? Те, кто я их называю люди, у которых есть ответы на вопрос. Я должна стать от без разницы, главное, чтобы люди понимали, как работать бизнес-процессы, которые они пытаются автоматизировать. Вот. И они проводят действительно ваш торрент. Обычно на это уходит два дня. Ну, там сессии по три часа, то есть два раза по 3-6 часов разрисовывать процесс, понимают действительно, что границы сервиса такие, и исходя из этого они его проектируют. Потому что если этого не сделать, то есть риск просто пальцем небо ткнуть и границы провести не в том месте и получить сильно связанную систему. Поэтому он во всей компании внедрен, все команды пользуются, и исключительно вот этого моего применяем, чтобы грамотно границы. Поэтому это инвестиция, она оправдана. Видели картинку, показывали, писать, сколько убер сейчас это стоит все привести к слабо связанной системе, это стоит. Вот. То есть не потратить 6 часов, что потом потратить миллиарды, ну, как бы так себе. Поэтому лучше потратить нас еще на самом деле вопросов 6. Надеюсь, ты готов. Я предупреждаю просто зрителей в зале. Значит, пока есть время, да, значит, подскажите: Исходный код сервисов находится в отдельном репозитории или в текущем, где лежат схемы? Исходный код сервисов находится в водяных репозиториях. Вот, мы никак это. То есть этот, здесь архитектура сделала, был сделан отдельный такой моно репозиторий, стоит целью, чтобы была единая точка контроля. Если мы как в каждом сервисе такие бы схемы рисовали, то было бы сложно контролировать. Вот. Сам код сервисов, его контролирует только сама команда, поэтому здесь их собирать. Поэтому Следующий вопрос: тогда интересно, как вы переходили на эту систему, если раньше было что-то иное? Переходили очень просто, как я уже сказал, что компания росла с относительно небольшой до крупной, и первый заход - это был того, что люди в конфликт изначально по своей схемы рисовали, но потом возникли эти проблемы, которые перечислил, да, что нотация непонятно, как принимать, непонятно, как отклонять, непонятно, как какая текущая актуальная версия, вот и прочее. То есть какое-то превью это позволяло делать, но формировать единую такую базу знаний не особо. Поэтому единственный плюс то, что мы там сразу стали использовать виджет для план, на котором можно было и схемы рисовать. Поэтому потом просто технический писатель перенес за две недели все схемы в репозиторий в соответствии с шаблонами. Потом была поставлена задача всем командам посмотреть на то, что там есть и актуализировать. Мы вот с этой точки стали считать счета уже такого прям плаценного ревью. Но пока на раннем этапе просто сказали: "Давайте сделаем просто актуально". Вот, а потом уже будем двигаться, потому что если было бы не актуально, и решение актуально, понимать было бы сложно. Вот, когда это были разрознены, у нас вопросы зала. Прошу вас. Здравствуйте, меня зовут Антон Райф. Подскажите, пожалуйста, вот обычно какое-то решение, но затрагивает не один сервис, а может закрыть, может быть, какой-то длинный процесс, и там будет несколько сервисов, несколько систем. Вот как у вас это матч? У вас одна дырка может включать какой-то комплексное решение или вы как-то развиваете по кусочкам, или вот как это происходит? Да, я сейчас еще не показал еще один вид разрешений, да, потому что он еще в таком не окончательном виде, да, но он есть. Это я, мы его называем Epic, да, то есть это как раз у то прошлого спрашивается, когда требуется решить какой-то комплексную проблему от бизнеса, и требуется участие там сразу МС. Там как раз дописывается общая схема, показывается их новая интеграции, то есть предполагается, что они уже есть, должны появиться. И от него, собственно, эти вот яркие, которые мы сейчас видели с вами, они как бы являются дочерью. То есть в нем общий концепт, да, потом какие изменения мы должны сделать в каждом сервисе для того, чтобы концепт реализовать. Вот. То есть вот такой вот, который решение у вас получается какая-то двухуровневая система? Сначала общая задача решается одной идиаркой, а потом и вы ее согласовываете, а потом для каждой, для каждого микросервиса приходит команда, пишет свою какую-то частную диарку, и вы уже их тоже принимаете? Да, изначально у нас была проблема это контролировать создание новых сервисов, потому что они появлялись очень часто, нужно взять под контроль. А на текущий момент они уже все есть, да, и теперь на них базируется какие-то разные решения, и возникла как раз необходимость вот это вот схему, схема, которая именно на какие-то Эпики направлены. То есть мы хотим там сделать новый вид, допустим, доставки, должны участвовать опять сервисов. Вот как и вот это отдельный разрешение, когда мы его согласовываем, соответственно, в каждом сервисе тоже происходит изменение, потому что какие-то новые интеграции появляются и так далее. Оно для них таким заявляется. Там. Спасибо. У нас на самом деле еще есть вопросы. Кирилл, ты готов на них ответить? Есть какой-то ограничение? Ну, я бы, у меня еще минут 15 есть. Давай попробуем на несколько вопросов. Остальные, если мы не успеем, мы уже зададите. Кирилл в Telegram, если вы не против. Ты же оставляешь контакт, правильно? Я помню, на последнем слайде сайт. У вас была цель - низкий порог вхождения для актуализации архитектуры. Но создается впечатление, что ведение дополнительных проверок, вовлечение процессов бы, и появление общего глоссария движения в другую сторону. Может, задача не решаемая? Здесь задача в плане ее достаточно интересно решать в том плане, что нужно найти баланс. Баланс между повышенной сложностью, да, какими-то сложными фреймворками, сложными ротациями, сложными документами на 50 листов. И вторая сторона, как бы, это то, когда вообще ничего не ведется в компании, не понимаю, что происходит, и как-то хаотично развивается. И вот баланс надо найти, чтобы мы не скатились в монархию, при этом не скатились бюрократия. Поэтому мы долго вот эти вот шаблона уверяли, старались из них оставить только то минимальное, что необходимо для принятия решения. Действительно, эта команда тратит время, действительно, это какой-то порог, да. Но на моей практике, поскольку помогает это став инженер в рамках домена, у него же руками биты, он соответственно, фактически вместе с ними это решение делает. Получается достаточно очень быстро. В среднем они тратят на это полдня. Вот. И горизонте жизни сервиса, как я уже говорил, от двух лет, до полдня - это ничто. Поэтому здесь порог действительно есть. Два дня SL, и действительно есть, да, мы на два дня действительно затормаживаем разработку, но в горизонте двух лет, как бы, это прям вообще одна 600, одна 700 всего цикла. Поэтому это небольшое время. Это не два месяца. Спасибо. Значит, еще вопрос: "Иван шторминг проводится какой-то упрощенный? Кто участник ивеншторминга для внесения информации в edr?" Ну, не упрощенный. Проводятся, как я уже отвечал, то есть на всю компанию, она тут конкретный процесс, который команда пытается автоматизировать. Собирается 10 человек, обычно из них 5 - это люди от бизнеса, которые понимают, как бизнес устроен, 5 айтишников, которые понимают, хотя бы понять баланс контекст и понимают, как, собственно, границу провести. Да, спасибо. Прошу прощения, тут может быть задваиваться вопросы. Какая документация у вас существует, кроме edr и артефактов из репозитория? Но документация еще продуктовые команды ведут, естественно, свои какие-то там наброски, но они-то в конфликт в основном делают, то есть какие-то идеи у них там, гипотезы, прочее, прочее, прочее. Вот, но архитектуре это отношение не особо не имеет, поэтому они могут вести где хотят. Последние два вопроса. Значит, как задается и ведется связь между двумя репозиторами: архитектурные и реализация? Сейчас, как я уже говорил, что на текущий момент связка выглядит через администраторов. То есть, когда производится развертывание нового сервиса, от администратора сверяет те запросы, которые команда есть по интеграции, с той схемы, которая была согласована. Если, допустим, согласовали там две интеграции на схеме, а сделали три, то им предлагают: "Идите как бы третью согласовывайте, потому что вы никому не показали, но при этом сделали". Как бы, естественно, вам рассказать ничего не будем. Но следующий этап, как уже сказала, эта идея, я надеюсь, что она сложится, это автоматизирует процесс, что если схема согласована с двумя интеграциями, автоматически открывается для интеграции. Если доработали, сделали третью, согласовали, то открывается третий интеграции, чтобы этого человека просто не участвовал. Это в целом выглядит как решаемая задача, потому что у каждого сервиса есть файлик в том же Xiaomi, в котором четко прописано, может ходить. Если вы научитесь генерировать из вот этих стрелочек этот велос яму, то вы будете открывать себе интеграцию. Здесь не особо сложно. Все. Спасибо. Последний вопрос: "Каким образом определяется, что текущая реализация напротив соответствует такой-то версии архитектуры?" Но определяется, соответственно, как уже я говорил, что когда администратор разворачивает, он теряется со схема. Не будет разворачивать то, что если решение не соответствует тому, что схеме. Мы продолжение этого вопроса: то же самое, что и до этого отвечал. Пока никак. А через неделю там взяли что-то добавили. Тут только рассчитывает на то, что если они пойдут к администратор доступ просить, он скажет: "У вас на схеме этого нету". И не согласует и доступ. В будущем мы хотим это автоматизировать, чтобы меньше было человеческих участия. Спасибо, что ответила. Это как раз один и тот же человек. Я думаю, что если он захочет, он точно в Telegram. Спасибо тебе большое за доклад. Спасибо за то, что осилил столько много вопросов. Было очень интересно, и даже по чату нашему, что очень много сообщений, которых я не прочитал, как комментарии.