Как DDD и Event Storming помогает декомпозиции на сервисы

Я предлагаю начинать и рада представить нашего первого спикера, это Кирилла Печинкина. Кирилл, основатель школы по микросервисной архитектуре Микроарш. Сама 2 года назад проходила обучение у Кирилла. Благодаря этому обучению точно в своей голове всё лучше систематизировалась про DDD, про Иваншторминг. И эти все знания, в принципе, эти 2 года я и применяла, когда мы проектировали все наши новые процессы, продукты. Кирилл, спасибо тебе за это. А сегодня Кирилл расскажет про DDD, как он помогает декомпозировать сервисы. А поэтому я передаю слово Кириллу.

Да, всем привет. А меня уже представили, поэтому предлагаю сразу начинать. И сегодня мы с вами поговорим про то, как такая методология, как DDD, Event Storming, да, помогает декомпозировать систему на микросервисы. И поговорим про DDD, Event Storming, микросервисная архитектура и Event Driven система, да, то есть система, которая основана на событиях.

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

Мой опыт начинался с разработки, да? То есть я практикующийся разработчик и до сих пор пишу код и на C#, и на Go, но в то же время с уклоном в архитектуру, да, то есть меня архитектура всегда интересовала, да, поэтому я вот так вот и разработчик, и архитектор вот в мире это называется Staff-инженер, да, то есть некий такой архитектор, который умеет и в код, и в проектирование. И работал в компании Cooper, да, в течение 3 лет. И там как раз у меня была такая флагманская задача, да, помочь компании перейти с монолитов, да, в микросервис и сделать это так, чтобы это не стало болью. И, соответственно, сегодня я с вами поделюсь про то, какие практики применяли, как они нам помогли и так далее. Ну и также, как уже было сказано, да, я являюсь автором нескольких курсов по микросервисам, по DDD, по чистой архитектуре и, в частности, про Event Storming, который мы сегодня также будем рассматривать. Ссылочки на них есть вот здесь.

И давайте приступим, да, ээ с основного тезиса, да, что 80% компаний, да, которые внедрили микросервисы, не ощущают заявленных эффектов, да, то есть вроде бы им обещали, что вот сейчас мы внедрим эти сервисы и будет нам счастье. Не будет так плохо, как в монолитах. У нас не будет всё падать разом, да, мы начнём очень быстро разрабатывать, да, но не знаю, как у вас, но я думаю, что многие ощущали, что стало всё просто сильно сложнее, быстрее мы разрабатывать особо не стали, да, просто теперь нужно не одно приложение деплоить в продакшн, да, а 50 или 100. И это порой проблема, да. И часто, когда мы в команде делаем какую-то фичу, нам нужно не просто её сделать, да, нам нужно пойти к другой команде, попросить у неё какую-то доработку, доработку в каком-то одном сервисе, втором, третьем, и у нас из-за этого скорость поставки, да, наоборот, ухудшается, да, потому что у нас появляется много зависимостей от других сервисов, от других команд. И, ээ, в этом, собственно, причина вот этого недовольства, которое вот показано на экране.

Но базовая, да, корневая причина, да, почему у нас, как у команды, которая владеет каким-то сервисом, возникает вот такая вот зависимость от других команд, да, почему мы от них сильно так стали зависеть. А причина зачастую следующая, да, это неверная декомпозиция, да? То есть мы нарезали систему на сервисы таким образом, что хотели бы, чтобы они были слабосвязаны, да, но получилось так, как получилось, да, сервисы все стали друг от друга сильно зависящими. И, соответственно, когда мы делаем какую-то функцию, мы вынуждены просить другую команду что-то доработать, да, чтобы наша функция тоже сложилась. И вот в итоге наш тайм, да, скорость поставки ухудшается. То есть, э, корневая причина - это неверная декомпозиция.

И, э, около 2 лет назад, да, вышла известная статья от Uber, да, где крупный бигтех гигант, да, признал, что сначала они хвалились долгие годы, что у них там несколько тысяч микросервисов. Это безумно круто. А потом они признали, что это как раз есть тот самый микросервисный ад, что их настолько много, что не нужно, и разработчик вынужден касаться сразу там пяти-шести сервисов, да, когда им нужно делать какую-то фичу, да, то есть это замедляет их производительность. Ну и, соответственно, признали, что это проблема, и начали там рассказывать, как они её решают. Ну, решают они весьма своеобразно. Вот про решение там не особо интересно, но то, что не признали проблему, это такой был прям сигнал, да, всему миру, что, наверное, стоит задуматься.

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

А мы не будем говорить в вакууме, да? То есть мы в докладе я сделаю некоторую легенду, и мы как раз по этой легенде пойдём, и я покажу некоторые даже демо, да, где мы это сделаем вместе. Соответственно, наша задача - это декомпозировать систему на микросервис, да, так, чтобы они были слабо связаны, да, возникает вопрос: а как, какие мы подходы должны применять, чтобы вот этого действительно достичь? И э мы эти подходы будем как раз разбирать. И также есть легенда, да, чтобы не быть голословным, показать всё на каком-то конкретном примере, да, по легенде нам нужно, к примеру, нанимать курьеров, принимать заказы, назначать их на курьеров, делать доставку, высылать нотификации, когда заказ был создан, и при завершении, да, а за каждый выполненный заказ начислять курьеру бонус, да, вот это условно наша часть системы или полностью система, которую нам нужно грамотно декомпозировать на микросервисе.

И как зачастую происходит вот такая декомпозиция? Все думают: "А, всё понятно, как бы старый добрый подход, нахожу все существительные, это и будут наши микросервисы. Курьер, заказ, да, там транспорт, ещё что-то". Но потом, когда образуется какой-то бизнес-процесс, выясняется, что все эти сущности друг с другом связаны, потому что именно они образуют этот бизнес-процесс. Вот у нас вот эта сильная связь и образовалась на ровном месте. А поэтому то, что я могу видеть, к примеру, из своего опыта, да, что зачастую команды, аналитики, разработчики, да, просаются делать дизайн просто не понимая сути бизнес-процесса, да, то есть мы не до конца понимаем, как выстроены бизнес-процессы вот в этом бизнесе, да, который мы хотим автоматизировать, но мы уже принимаем решение о том, как нужно сделать микросервисы. И теперь задумайтесь, да, а можем ли мы принимать правильное решение, да, в том, что мы до конца не понимаем? И здесь отчасти есть роль аналитика, да, понять, да, понять, как это всё устроено, чтобы потом грамотно вместе с архитектором либо самостоятельно, либо с командой провести границы микросервисов. В этом вот, собственно, практика Event Storming и помогает, которую мы сегодня будем с вами разбирать.

Если мы просто голделы, начиная просто резать сервисы, не понимая, не проводя какого-то претоанализа, да, мы получаем тот самый микросервисный ад, да, про который я говорил. Да, куча микросервисов, которые делают какую-то функцию, все друг с другом связаны. Ну и вот те самые проблемы, а, с которых мы начинали. А, соответственно, чтобы в такую ситуацию не попасть, да, мы должны подходить к декомпозиции осознанно, исполненно понимаемым процессом, да, но возникает вопрос: а как, да, то есть применять какие-то тяжеловесные практики типа BPMN, либо ещё какие-то более сложные, да, и плюс я, к примеру, там условно или вы как аналитик не всегда понимаете полностью, как устроен процесс, да, это понимают какие-то другие коллеги, да? То есть, если мы рисуем это всё самостоятельно, то мы не все грани видим, и мы опять же-таки можем допустить какую-то ошибку. А поэтому эти практики тоже имеют, конечно, свои плюсы, да, но имеют и некоторые минусы, что с помощью них быстро, достаточно сложно понять, как устроен процесс. Это занимает достаточно продолжительное время. А поэтому сегодня мы с вами поговорим в докладе про такие практики, как DDD, да, поймём вообще, как нам DDD помогает в микросервисах. Если вот говорить про ситуацию с внедрением микросервисов с 2015 года и вот, наверное, до 2022, то основная ошибка большинства компаний была в том, что они научились делать микросервисы технически, но вообще не применяли DDD для декомпозиции, да, то есть просто делали сервисы, потому что можем, но границы по DDD не проводили. И вот сейчас, собственно, DDD набирает обороты и становится популярным подходом, потому что все поняли, что, ну, так больше нарезать нельзя. Это приводит к проблемам. Поэтому мы с вами поговорим про DDD, а, поймём, как оно помогает в микросервисной архитектуре. Далее мы поговорим, что микросервисная архитектура может быть построена синхронно, да, через синхронные вызовы и через события. Поговорим, чем события для нас более выгодны, и плавно подойдём к практике Event Storming, да, потому что а это у нас некоторая база, да, а Event Storming - это как раз процесс, да, который нам помогает анализировать, да, анализировать процессы и понимать, где же у нас граница одного сервиса и начало другого. Соответственно, вот такой у нас будет план. А давайте по нему и пойдём.

Начнём с DDD, да, и поговорим про стратегические паттерны, да. В DDD у нас есть, э, такие, скажем так, два крупных раздела. Это стратегические паттерны и тактические. Тактические они больше нужны для разработчиков, да, то есть как там писать код в соответствии с DDD, чтобы код был выразительный и так далее. А стратегические они больше вот про анализ бизнеса, выделение субдоменов, баунд контекстов, э, выделение сервисов, модулей в монолите и так далее. Поэтому вот они как раз для нас, э, в первую очередь интересны, если мы говорим, а, про микросервисы.

А давайте приведём пример, да, то есть там в стратегических паттернах есть несколько несколько таких, ну, терминов, да, которые мы должны обсудить. Во-первых, это domain, да, сама практика называется Domain Driven Design, да, соответственно, проектирование от предметной области. Domain - это предметная область по-русски. И что такое domain, да? То есть domain - это, по сути, то, чем занимается компания. Да, то есть основная её суть, если, к примеру, возьмём а Cooper, да, это доставка продуктов, да, это вот основной бизнес, если мы спрашиваем, чем компания занимается, доставкой продуктов, а, Starbucks, да, продажа вкусного кофе, Перекрёсток, да, торговля продуктами, товарами, да, ну и так далее. Этот список можно продолжить. То есть это основная суть бизнеса, но также бизнес может быть очень большим, да, и domain он может быть очень здоровым. А поэтому есть такое понятие в DDD, как субдомейн, да, то есть какой-то поддомен, под какая-то предметная область, да, потому что большие компании зачастую состоят из каких-то разных направлений, которые вместе образуют как раз ту ценность, которую даёт компания. Если мы, допустим, будем разбирать пример Starbucks, да, у него основной domain - это вкусный кофе, да, то есть это и основная их главная цель, зачем они вообще существуют, но как мы её достигаем, через какие поднаправления нашего бизнеса, да, закупка лучшего кофе, найм персонала, аренда помещений в правильных местах, реклама привлечения и, конечно же, разработка каких-то там рецептов, меню, обжарка кофе там и вот это всё и так далее. Мы здесь видим, что вот эти вот субдомены, да, они все вместе образуют результат, да, основной domain, да, поэтому основной domain всегда можно разбить на какие-то поддомены. И вот наша задача, да, когда мы систему анализируем, декомпозируем, да, научиться находить эти субдомены по той причине, что если мы хотим достичь, чтобы сервисы были слабо связаны, а мы можем это делать по субдоменам, потому что сами субдомены они слабо связаны априори, да, к примеру, рецепты меню и аренда помещений, вот как они связаны, да, у них изначально связанность очень низкая. Рекламное привлечение и, к примеру, там найм персонала, да, тоже слабо связано. То есть, если мы проводим декомпозицию по субдоменам, мы сразу же получаем слабосвязанные микросервисы, и у нас вот этого зависимости между командами, между сервисами становится минимальные. Но при этом субдомены могут быть достаточно большими, да, потому что закупка лучшего кофе, ну, это весьма широкая такая область, там может быть много чего э внутри. И поэтому в DDD есть ещё такой термин, как bounded context, да? В целом на сегодняшний день в большинстве случаев bounded context один к одному соответствует субдоменам. А bounded context - это конкретное техническое решение. То есть и субдомен - это какое-то просто направление бизнеса, а bounded context - это конкретное техническое решение, которое автоматизирует, да, эту область бизнеса. К примеру, если мы говорим про закупку лучшего кофе, да, то у нас может быть прямая поставка, да, какая-то IT-система, которая реализует прямую поставку и система, допустим, участия в тендерах, где мы тоже закупаем кофе, да? То есть это какой-то конкретный дизайн, который мы сделали, чтобы решить эту проблему субдоменом. Поэтому любой субдомен может быть декомпозирован либо на один bounded context, либо на несколько. И, э, в микросервисах, если говорить про декомпозицию микросервисов, там есть два паттерна, да, это декомпозиция по субдоменам и в то же время можно декомпозировать по контекстам, да, и то, и другое даёт вам слабую связанность. Вот именно про эти два паттерна люди последние 6 лет и забыли. Вот. А сегодня они вспомнили про это, вспомнили про DDD, именно поэтому мы с вами про это говорим.

А давайте теперь перейдём к микросервисам со стратегическими паттернами DDD. Мы в целом с вами уже познакомились, разобрались, поняли, как они нам помогают. Давайте теперь поговорим про DDD и микросервисы. А, как я уже сказал, да, микросервисы без DDD всё ещё выглядят вот так, да, как микросервисный ад, да, потому что декомпозиция неправильная, куча сервисов, они друг с другом связаны, всё плохо. А когда мы говорим про микросервис с применением DDD, да, ситуация уже сильно меняется. Мы нарезаем сервисы в соответствии либо субдоменов, либо bounded contexts, да, и априори, как я уже сказал, получаем прямо с коробки слабую связь между командами, между сервисами, да, и получаем, соответственно, тот профит, да, и тот результат, который в целом вам всем обещали, когда сказали, что микросервисы это очень удобно и классно, да, вот только при таком подходе вы получите реально эти профиты. А мы можем завернуть каждый bounded context или субдомен в отдельный микросервис, да, и получить слабосвязанные сервисы, которые можно развивать достаточно независимо друг от друга.

И здесь важно поговорить про плохую, хорошую декомпозицию, да, и понять вообще, чем хорошая декомпозиция отличается от плохой, да, вообще как это пощупать, как понять. Плохая декомпозиция, да, то, когда у вас на уровне сетевого взаимодействия спагетти код, да, то есть сервисы сильно коммуницируют, вам бы так не хотелось. Сильная зависимость, да, один сервис упал, ваш сервис тоже упал, да, это сильная зависимость. Не то, чтобы мы начали строить какую-то классную такую устойчивую систему, да, наоборот, у нас есть проблема. А часто ошибки для новых изменений. Где-то что-то поменяли, вам нужно ещё менять 10 сервисов. Это время, риски, проблемы, инциденты, да, тоже, ну, результат плохой декомпозиции, неочевидные связи, да, что-то произошло, произошёл какой-то сайд-эффект, да, тоже результат плохой для композиции. Ну и последние избыточно долгие запросы, да? То есть если у вас запрос с приложения, к примеру, мобильного приходит на масштейзатор и он у вас отправляет его на конкретный микросервис, да, сервис в базе данных, выполняет какую-то логику, отдаёт, да, это самый самый быстрый вариант, да, у нас нет кучи походов в другие сервисы, потому что он от них не зависит, да? А если он уже от них сильно зависит, то у него начинается синхронный подход сюда, тудасюда. Суммарно у вас скорость ответа, да, падает, да, то есть запросы становятся долгими. Если там ещё один из этих сервисов падёт, не дай бог, то в целом и сам запрос не выполнится. А поэтому плохая декомпозиция, она приносит нам очень много проблем, да, которые я сейчас подсветил.

А хорошая декомпозиция, она наоборот приносит нам, э, как бы некоторые профиты, да, и признаки хорошей декомпозиции, да, что система разбита на слабо связанные сервисы, вам не приходится постоянно ходить коллегам что-то дорабатывать. А между сервисами слабые связи, да, то есть у вас нет кучи синхронных походов в другие сервисы в момент вызова, да? То есть там либо есть какое-то асинхронное сообщение, которое вы считываете к себе в базу данных, кладёте и потом его используете в процессе своей работы. Вот, в общем, связи не сильные. И ээ большинство изменений, да, когда приходит какая-то задачка, допустим, от продукта, мы не ставим 50 задач на коллег, да, из других команд, да, а мы там 80-90% работы выполняем в своём сервисе, да, и вот этих вот задач вовне их минимум. Если задач вовне много, да, то команда ваша, да, она по сути не разрабатывает, она ждёт, когда другие коллеги сделают, и тогда она просто начнёт интеграцию. Вот это ожидание - это простой, а простой - это потери денег для компании. И, э, соответственно, опять же-таки при хорошей декомпозиции, да, у нас внутри сервиса какой-то подпроцесс, да, вот если мы возьмём один такой длинный бизнес-процесс, да, он состоит из каких-то подпроцессов. Если мы какой-то подпроцесс завернули в один микросервис, да, то внутри сервиса может быть очень активная коммуникация для решения какой-то проблемы. Но дело в том, что внутри сервиса между классами это нормально, что активная коммуникация, потому что она происходит в оперативной памяти, а это просто работает очень быстро. Это просто там в десятки раз быстрее, чем работа по сети, когда мы с другими сервисами связываемся. Поэтому при хорошей нарезке сервисов у нас запрос приходит в сервис и внутри него как бы процесс крутится, да, и это работает очень быстро, да, если сравнивать с каким-то сервисом, с какой-то группой сервисов, которые с друг с другом взаимодействуют. А поэтому хорошая декомпозиция, она нам даёт очень много преимуществ. А, и вот сегодня мы как раз будем добиваться той самой хорошей декомпозиции, да, будем показывать, как к ней прийти.

А, немножко поговорим про тактические паттерны, да? То есть это паттерны, которые на самом деле интересны больше разработчикам, да, но тем не менее здесь про них тоже имеет э смысл рассказать, да, чтобы в целом понять вообще из чего это состоит, да, что у него на входе, что на выходе и как нам это всё встроить вообще в общую систему. А когда мы говорим про тактический паттерн DDD, да, то там есть такое понятие, как доменная модель, да, в целом доменная модель ну в аналитике она тоже достаточно часто встречается. То есть фактически это то, из каких сущностей наш сервис состоит, какие там будут классы, как они будут взаимодействовать, какие у них будут методы и так далее. И здесь мы, к примеру, видим, что у нас вот есть такая доменная модель, которая состоит из нескольких классов, да, у нас есть user, а, корзина и товар, да? То есть здесь, видимо, user может оформить корзину, положить в неё товар и сделать checkout, да, то есть сделать оформление заказа. Это как раз какой-то подпроцесс. А также в тактических паттернах DDD, да, принято сущности не просто в вакууме держать, да, там item отдельно, basket отдельно, status отдельно, да, то есть всё с ничем не связано, не образует каких-то смысловых конструкций, это плохо, да. Поэтому в DDD есть такой термин, как агрегат, да? То есть это кластер из каких-то доменных сущностей, да, которые образуют какой-то, ну, осмысленный объект, да. К примеру, как вот здесь мы видим, что user со статусом, да, это осмысленный объект, корзина с позициями, да, потому что корзина без позиции, ну вот кому она нужна без позиции, или позиция без корзины, тоже достаточно бессмысленно. И вот когда мы классы объединяем в такие кластеры, да, то вот их как раз называют агрегатами. И важный момент, да, почему я про эти агрегаты говорю, что у агрегатов есть такое понятие, как доменное событие, да? То есть, когда в а в агрегате, да, что-то происходит, да, допустим, он поменял своё состояние, да, и, к примеру, заказ был оформлен, то мы можем выбросить доменное событие, к примеру, Basket Confirmed, да, то есть корзина была оформлена или там корзина была очищена, корзина была отменена, а заказ был оплачен, там юзер был заблокирован. То есть таких доменных событий может быть сколько угодно. Я про них специально говорю, потому что Event Storming, про который мы будем говорить в конце, он как раз про вот эти события, да, он про поиск этих событий, да, чтобы понять, что у нас в нашем процессе происходит. И потом, да, мы как раз от них уже переходим к агрегатам и понимаем, с чего у нас наша доменная модель будет создана. И если говорить вот про микросервис, да, вот я поместила все эти агрегаты внутрь него, то есть внутри микросервиса понятно, что находится доменная модель. И также у микросервиса есть входы и выходы. Если входы они воздействуют на use cases, которые есть в этом сервисе, да, то есть что он может делать? А на выходе сервиса, да, у нас, наверное, мы вот эти доменные события должны заворачивать в какие-то интеграционные события и там отправлять в Kafka либо в RabbitMQ, либо ещё куда-то. Вот с сердцевинкой мы разобрались, у нас возникает вопрос, да, вот как нам понять, что у нас там на на входе и на выходе. Здесь у нас два варианта, да, асинхронная коммуникация и синхронная коммуникация, да, поэтому про неё тоже хочется поговорить, потому что синхронная коммуникация, она хоть и допустима, но она, на мой взгляд, негативно влияет на вообще в целом хорошую декомпозицию, да, потому что если вам явно нужно куда-то пойти, что-то взять, это значит, что, видимо, вот то, что-то находится там, оно, возможно, часть вашего сервиса и зачем-то вы туда за этим ходите куда-то в сторону. А, поэтому поговорим про Event Driven микросервисная архитектура, да? То есть микросервисная архитектура, основанная на события. Про синхронные и про асинхронные интеграции.

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

три корзины или накидываете ресурсов на этот сервис корзины, он у вас начинает работать, да? При этом в каталог теперь нагрузка высокая. Вы его масштабируете, да, там каталог ещё куда-то ходит, вы третий сервис масштабируете, да? То есть у вас в этой цепочки а очень сложно найти баланс, сколько куда ресурсов накинуть, чтобы система реально выдавала максимум. А это достаточно сложно.

Ну и последнее - это ухудшение UPTE, да, про что я уже частично говорил, да, что чем больше у вас вот таких сервисов в этом синхронном вызове, тем у вас хуже, да, по очень простой причине, что падение любого из этих сервисов приводит к остановке процесса. Чем больше сервисов, тем больше вероятность, что у нас этот процесс остановится, да. Поэтому uptime, да, тоже пропорционально у нас снижается. Если в этой цепочке есть, допустим, все сервисы прямо там три девятки, всё прямо топ, но один сервис какой-то плохенький затисался, да, он как раз вам попортит всю статистику вообще всего этого запроса. Поэтому здесь синхронных интеграций, несмотря на то, что я знаю, что все их любят, обожают, у них есть очень много проблем. И в целом я вот рекомендую от них тоже отходить. Чем быстрее вы это сделаете, тем лучше.

А давайте поговорим про асинхронная коммуникация. Какие у них плюсы, да? То есть здесь плюсов достаточно много. Это, во-первых, быстро, да? То есть если я, к примеру, там из каталога заранее зареплицировал какой-то усечённый э набор данных касательно товара, да, то теперь, когда мне придёт, к примеру, какой-то запрос в корзину, положи такой-то товар, да, я уже не пойду в каталог спрашивать цену, я пойду к себе в свою базу данных, и у меня там уже есть прайс, да, то есть мне идти в каталог уже не надо. В свою базу данных я пойду очень быстро. Она у меня под ногами, доступ для неё быстрый, поэтому запрос отрабатывает тоже очень хорошо.

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

Далее легко масштабировать, да? То есть у меня запрос извне приходит один на корзину, второй на каталог, да? Если я вижу, что у меня, к примеру, каталог не вывозит, я просто масштабирую каталог, да? Если я вижу, что у меня корзина не вывозит, я масштабирую корзину, у него нет каких-то синхронных вызовов, да, от чего она там зависит. Она вот только от БД зависит. Поэтому либо базу буду масштабировать, либо саму корзину буду масштабировать. И всё очень просто, да. У меня единственная, скажем так, [музыка] единственная точка, да, которой я должен управлять, это конкретно сервис, у которого есть проблемы. Я на него накидываю ресурсов и понимаю, лучше стало или хуже. Мне и нужно уже вот этот граф в зависимости строить и понимать, где там мне в нём ресурсов надо накинуть.

И а последнее - это улучшение Upтайм, да, как я уже говорил, если каталог у нас не работает, то корзина работает. Если корзина не работает, то каталог работает, да? То есть в целом за счёт того, что они заранее обмен менялись данными, они как раз имеют ту самую слабую связь, да, которую мы сегодня в течение данного доклада говорим. То есть вывод следующий, да, что асинхронные коммуникации, они вас уже подталкивают э и приводят к той самой слабой связи между сервисами, которую все так хотят получить. И как итог, да, слабая связь приводит к независимой разработке, частным поставкам и вот тем самым плюшкам микросервиснатуры, про которую все говорят.

И, соответственно, когда мы говорим про микросервис, да, которые я показывал в самом начале, да, здесь у нас стояли вопросики, мы думали: "А как же там лучше нам выстроить канала коммуникация, да? Здесь мы видим, что в идеале, да, сделать здесь очереди на входе, на выходе, да? То есть, если у нас приходит какой-то запрос с фронт-энда, да, пусть мобильное приложение что-то от нас хочет, да, здесь понятно, HTP запросы к нам приходят, мы вызываем юзкейсы, они вызывают методы в агрегатах, агрегат что-то делает, выбрасывает события, и уже оно идёт по сети. Э с фронтм всё понятно, да, это, естественно, синхронные запросы, к ним вопросов нет. Но когда к нам обращается какой-то другой сервис, да, к примеру, там в другом сервисе юзер был создан или юзер был заблокирован или, к примеру, там остатки товаров на складе поменялись, да, то здесь синхронные вызовы использовать ну неэффективно, да, по той причине, которую мы с вами обсудили, да, нам гораздо проще принять событие, среагировать на него, вызвать какой-токейс, да, задействовать какой-то агрегат и потом поменять его состояние. и уже там выбросить событий или нет. То есть вывод, да, что асинхронная интеграция, это это большой плюс. А это мы тоже поняли, да? То есть мы разобрались в стратегических паттернах DDD, поняли про микросервисы, поняли, что микросервис лучше делать на событиях.

И вот тут мы как раз с вами подходим к самому важному, да, к самой вишенке данного доклада, это ковеншторминга, да, потому что у нас возникают вопрос, да, вроде всё понятно, да, там DDD поняли классно, микросервисы тоже всё вроде понятно, проблема понятна, что синхронная коммуникация на событиях - это классно, понятно, да, но самое главное, непонятно, да, а как находить границы сервисов, да, и строить те самые слабо связанные микросервисные системы, да, основаны на событиях, да, то есть как нам это сделать? И вот здесь как разшторминг и решает данную проблему. А это вот методология, это некоторая наслойка на DDD, да, некоторый визуальный, скажем, такой фреймворк, да, который позволяет как раз визуализировать ваши процессы и потом проводить декомпозицию в соответствии с принципами DDD. И судя за название шторминг, да, то есть событийный штурм, как вы понимаете, всё основано на событиях, да? То есть мы, когда проводим анализ процесса, мы не просто действия какие-то юзеров собираем, там, что юзер сделал, мы собираем факты, мы собираем события, которые произошли в этом процессе. И за счёт того, что сам подход основан на поиске событий, да, когда мы начнём резать систему на сервисы, у нас система, ну, с вероятностью 95% получится как раз основанное на событиях, да, и на синхронах взаимодействиях между сервисами. Поэтому мы как раз и достигаем самых лучших подходов.

И, э, давайте поговорим немножко прошторминг, да? То есть, если не встречались, я сейчас про него расскажу, покажу дамо пример. Что это такое занотация? А, фактически это очень простая нотация. А простая - это это её фишка. В этом весь смысл. А смысл в следующем, да, что когда мы, к примеру, как аналитик сидим и сами что-то там скрупулёзно целый месяц изучаем, да, то, ну, во-первых, это месяц. Во-вторых, у нас не факт, что есть знания о процессе, да, поэтому мы его изучаем. А есть какие-то люди, которые что-то знают, мы их там выдёргиваем навстречи либо на какие-то созвоны, что-то у них спрашиваем, да, как-то по крупицам это собираем и у нас в конце месяца результат. А, ну в чём проблема, да? Во-первых, мы с каждым работаем в один поток, да, сначала с первым, потом со вторым, потом с третьим, потом с четвёртым. Это просто медленно. Во-вторых, а-э зачастую люди, с которыми мы взаимодействуем, они сами не до конца понимают процесс, да? Ну это нормально, да? То есть вот человек хорошо знает вот эту часть, а что там дальше, он вообще не знает, знает там второй. Вот вы бегаете ко всем. А часто бывает так, что он думает, что знает, на самом деле не знает. Это тоже нормально. Такое бывает. А, к примеру, ну вот примеры жизни, да? То есть методолог знает, как проводить, э, там какие-то документы в офисе клиентском, но зовёшь навстречу какого-нибудь кассира, который в этом офисе работает, и он говорит, что они так уже 5 лет не делают. И вот у них начинается друг другом спор, выяснение, как правильно. И вот в результате этого спора рождается истина. И вот эванрминг - это способ, да, когда вы не бегаете ко всем людям точечно, да, вызовите их всех на одну встречу. Все, кто все, кто так или иначе понимает в этом процессе, каждый понимает свой кусочек. И вследствие коммуникации этих людей, да, вы решаете несколько проблем, да, во-первых, актуализируете сам процесс, крупиться его собираете, во-вторых, работаете в несколько потоков, да, то есть эти люди параллельно накидывают задачки, не задачки, а карточки, да, и соответственно мы получаем картину не за месяц, а буквально там за две встречи. В-третьих, они на этой встрече с друг другом спорят. Ну, спорят в хорошем смысле, да. Вот как я привёл пример кассира и методолога, и они находят истину, и схема получается актуальна сразу. А если бы вы точечно каждому пошли, вам бы один сказал одно, второе другое. Вы бы это на схему положили бы, и казалось бы, что она такая и должна быть. А на самом деле нет. На самом деле она не актуальна в голове. И вотминг вследствие вот этого диалога позволяет её актуализировать.

И помните тот самый тезис, да, с которого мы начали в самом начале, да, мы сказали, что нельзя грамотно декомпозировать систему на микросервиса, если мы не понимаем, а сам процесс, который в этой системе протекает. И вот как разшторминг - это способ понять этот процесс и сделать это коллективно в виде некоторого воркшопа вместе с коллегами. Именно поэтому нотация очень простая, потому что когда вы позовёте касира, да, и будете с него, к примеру, требовать знаний BPмен, чтобы он вам нарисовал или умель, да, он скажет: "Я этого не знаю, я пошёл, всё, я в уголок, до свидания". И что получится? Да, встреча неэффективная, вы знания из него не получили, она по сути провалена. А когда человеку показываешь просто семь и сколько их тут? восемь восемь разноцветных карточек и плюс они ещё на разных этапах участвуют, да. На первом этапе у нас участвует только одна единственная карточка - это domain event. Ему говорят: "Просто вот пиши на оранжевых карточках события, которые ты знаешь". Да, там клиент пришёл, клиент ушёл, да, там клиент подписал документ, он думает: "А, ну всё понятно, что сложно беру, просто пишу". Да? То есть вот этот лёгкая нотация позволяет вам подключать абсолютно людей с разным бэкграундом. Не айтишников, не аналитиков. кого угодно, продуктов, стейкхолдеров, кассиров, э, рабочих, да, то есть всех людей, которые так или иначе знают этот процесс. Поэтому простота - это вот та самая фишка, именно для этого она и создана.

А с точки зрения самих карточек, они они имеют разные цвета, и вот эта разная расцветка - это как раз, ну, некоторый маркер, да, что эта карточик значит. А agгрегаate мы сегодня с вами уже частично проговаривали, да? То есть это класс, да? внутри доменной модели. А команда - это некоторые действия, да, которые клиент делает, допустим, оплатить заказ, да, там заблокировать юзера, а зарегистрироваться, да, то есть действие - это команда. View - это какая-то наоборот модель чтения, да, то есть когда мне что-то на экране показывают, да, я что-то визуально вижу, допустим, каталог товаров, карточка профиля там и так далее. А доменное событие - это какой-то результат выполнения команды, да? Допустим, команда юзер заблокировать пользователя, да, это действие, а результат этого действия - это пользователь был заблокирован, да, то есть доменное событие. То есть это какой-то факт, который уже произошёл в прошлом. Аternal system - это любая внешняя система, да? Допустим, если вы взаимодействуете вот в рамках своего процесса с какими-то внешними системами, с какой-нибудь 1S вашей компании, да, которую вы, к примеру, там никогда не видели, она где-то там находится, и просто в IP её уходите, да, вы можете вполне её как external system показать. Вы её не собираетесь переписывать, не собираетесь менять, вы её просто потребляете какие-то внешние API, да, там, а, SMS-сервер, а, и прочие, прочие там какие-то интернет-сервисы, да, тоже может быть как External System. Эктор, да, Эктор - это по сути человек, именно вот человек, вот прямо живой человек, не как в Умейле, да, где там Эктора может быть кто угодно, там система и человек, и не человек. Здесь именно это вот живой человек, который выполняет какое-то действие. А вот External System - это вот как неживой. А полиси - это некоторые правила, да, то есть правила, когда мы должны реагировать на события, да, к примеру, можем сказать, что у меня было событие, допустим, пользователь заблокирован. В полисе я могу написать, что если пользователь был заблокирован, то заблокировать ему счёт и полис затригрит уже другую команду. И вот у нас как раз начнётся вот эта вот циклическая, не циклическая, а начнётся вот этот флоу. А повторяемый, да, то есть одно повторяет другое. Вот как вот здесь показано, да? То есть Эктор посмотрел на какой-то экран, выполнил какое-то действие, действие изменило либо агрегат, либо внешнюю систему, произошло какое-то доменное событие. В полисе мы на него отреагировали и, видите, опять запустили другую команду, агрегат, домена события. Здесь опять бы могла бы быть полиси, ну и так далее. То есть этот процесс может расписывать бесконечно долго, от самого начала до самого конца.

И давайте как раз, а посмотрим на некоторую демонстрацию, да, соответственно, вот здесь, а, у меня демонстрация, и здесь как раз показан пример, а, эшторминга, а, где у меня есть, э, легенда, да, что мне нужно нанимать курьеров, да, принимать заказы. Ну вот всё так легенда, которую я в самом назна в самом начале озвучивал, да? И вот здесь она показана, да, что мы выстрелили как раз этот процесс, да, как происходит это мы собираем, по сути, а всех интересантов данного процесса, да, кто так или иначе про него что-то знает. Обычно эта группа там до 10ти человек. И, э, говорим вам: "Ребята, давайте-ка вы вот все события выпишите и потом мы их разложим по хронологии, образуем какой-то некий такой процесс". Здесь сложно за 40 минут рассказать детально, что такое, как это всё происходит, как это происходит в Workshop. Здесь мне, наверное, важно показать вам эффекты, которые мы здесь можем получить после этого. Аа, расписываем события. Вот они оранжевые, да? Потом обогащаем их, э, экторами, действиями. View. Да. И у нас образуется такой, а, бизнес-процесс, да, Мы видим, что соискатель смотрит на анкету, он её отправляет, у нас, э, какая-то класс в системе создаётся, событие, анкета заполнено, затем его нанимаем, сотрудник нанят, да? То есть вот у нас пошёл процесс, да? Тут мы добавляем товар в корзину, затем оформляем корзину, да, потом мы создаём заказ, затем назначаем заказ на курьера, а затем у нас заказ начинает доставляться. Ну и затем заказ завершён, да? И здесь мы уже в конце видим, что начисляем бонусы, отправляем тификации и так далее. Вот так вот, собственно, у нас так этот процесс и выглядит.

И здесь важный момент, да, присторминге, да, вот мы этот процесс расписали, да, возникает вопрос: "О'кей, а что дальше-то?" Ну, расписали, расписали. А здесь есть такое понятие, как ключевые события. Вот они здесь показаны. То есть такие события, которые мы делаем чуть больше, да? То есть вы когда всё расписали, вы начинаете задаваться вопросом как сами, так и всем участникам, да? И вы говорите: "Ребята, а вот расскажите в этом процессе, где у нас вот какой-то подпроцесс дошёл до какого-то, ну, промежуточного результата, да, где мы вот можно сказать, что вот этот подпроцесс завершился, начался начался следующий подпроцесс, и участники начинают думать, да, где же это? И финал процесса - это зачастую какое-то событие, да, потому что событие - это свершившийся факт. И вот это может быть как раз финалом этого процесса. К примеру, если мы говорим про вот этот кейс, да, то сотрудник нанят это, наверное, финал процесса найма, да, я думаю, согласны. Мы его там нанимали нанимали, и вот мы его наняли. А вот этот процесс, да, мы добавляли товар в корзину, там данные вводили, корзина оформлена, да, это тоже финал процесса, связанного с оформлением корзины, согласитесь. Да. То есть мы можем провести здесь вот такие вот линии и сказать, что это эти подпроцессы были завершены. Далее мы создали заказ, назначили его на курьера, он начал доставляться, курьер его доставил, заказ выполнен. Тоже результат, да, тоже можем сказать, что это итог, да, этого подпроцесса. Далее, мы сказали, что у нас по легенде мы должны отправлятьфикации и начислять деньги на бонусный счёт. О'кей. Бонусы начисленные - это тоже результат, да, тоже можем здесь повести линию, сказать, что это граница сервиса. Ну итификации здесь всё просто. А поэтому вот мы видим, как намшторминг, да, помогает как раз проводить декомпозицию, да, то есть мы процесс разрисовали, потом нашли какие-то подпроцессы, и вот именно по подпроцессам мы эмзать не по сущностям, а по под процессам. Это ключевой момент. И вот здесь, собственно, я эту нарезку и произвёл, да? То есть вот мы порезали и, соответственно, здесь видим, что мы как раз а по сделали это по ключевым событиям, да, то есть мы сделали сервис взаимодействие с персоналом, да, то есть где мы его нанимаем. Сервис корзины, где у нас под процесс оформления корзины, а сервис доставки, да, где у нас происходит назначение заказа и выполнение сервис нотификаций, да, и сервис бонусов, да. И здесь, когда мы про это говорим, то здесь, э, так, да, к этому чуть позже прийдём. А здесь важный момент, да, что мы можем после вот того, как провели вот этот эту декомпозицию, мы должны, конечно же, посмотреть на вот эти вот точки стыка, да, потому что в течение всего доклада я рассказывал про то, что мы должны добиться слабой связи, да, а вдруг а вдруг мы не добились. А, поэтому здесь есть вот такой вот, скажем, такой вот слайдик, да, где у нас есть хороший, плохая декомпозиция, да, вот эта плохая, где всё совсем связано, да, один сервис очень сильно связан с другим, они постоянно коммуницируют. И хорошее хорошее, да, где у нас внутри сервиса какой-то подпроцесс, в другом тоже подпроцесс, между ними просто какой-то контракт, где один сервис другому что-то отправил. Вот. И, соответственно, вот этот вариант, он, э, мы должны его добиться, собственно, в нашей системе. И вот здесь давайте посмотрим, получилось у нас или нет. Если мы, к примеру, поменяем процесс а найма, да, вот мы по-другому начнёмнимать не через анкету, там через, не знаю, там через какой-нибудь там нейросеть. О'кей, мы вот здесь меняем процесс найма. Всё равно у нас на выходе будет сотрудник нанят и всё равно будет отправлено сообщение в сервис бонусов, да, чтобы здесь создать бонусный счёт, да, то есть бонусный счёт никак не поменяется от того, что мы там по-другому людей нанимали. Связь слабая. А давайте посмотрим на корзину и доставка заказов. Да, мы можем здесь её оформлять вот через визуальный интерфейс. Завтра решим, через Telegram, послезавтра, не знаю, там ещё каким-то образом. Доставки заказов вообще всё равно, как в оформляте корзину. И главное, контракт, чтобы корзина была оформлена, и она уже начинает выполнять свой процесс. То есть декомпозиция по подпроцессом, да, вам гарантирует, что в случае изменения в этом подпроцессе это изменение будет локализовано внутри сервиса. А вот вы и получаете ту самую слабую связь как между командами, так и между сервисами. А, и вот в этомшторминг вам и помогает, что он вам позволяет разрисовать этот процесс, потом найти ключевые события, выделить под процессы и уже по ним принять какие-то решения.

А, и это всё можно перевести в техническую схему, да, вот здесь она показана, да, что стрелочки, которые были от события к от события к другому сервису, они преобразуются в стрелочку от сервиса в очередь и от очереди к другому сервису, да, Мы видим, что за счёт примененияшторминга мы как раз достигли, ну, факта, да, построения системы распределённой на микросервисах, которые слабо связаны и которые сразу же у нас получились на событиях, да, и у нас здесь в системе нет ни одного синхронного вызова, да, потому что мы изначально как раз декомпозицию делали, а, от событий. Вот. А-а, и давайте обратно вернёмся к презентации. И вот итоговая схема, да, которую я здесь хотел вам показать про связанности с зацеплением, да, мы уже проговорили, да, то есть в целом ваш результат, да, который у вас должен получаться, независимо от того, принимаете вышторминг или нет, он должен быть вот таким, как сверху, да, чтобы внутри сервиса был какой-то подпроцесс, он транслировал какое-то своё состояние, другой сервис на это состояние реагировал, начинал делать что-то своё. Если же у вас вот так, да, вот при синхронном взаимодействии именно так и получается. Ко мне пришёл запрос, я там в 10 сервисов иду, они мне отвечают, я им отвечаю. Вот это вот эта нижняя штука, да, и здесь вряд ли у вас получится слабая связь между сервисами.

А давайте подведём некоторые итоги, да, данного доклада, да, мы проговорили с вами сразу, на самом деле, несколько практик, проговорили их связь с друг другом, поняли, как они друг друга дополняют. А и результат, да, итог, который я могу подвести, да, что декомпозиция должна происходить в соответствии с подходами DDD, а межсервисное взаимодействие на событиях, оно более удобное, да, и чтобы найти вот эти границы, а, сервисов, да, применениешторминг [музыка] нужно применять нштоминг. И, собственно, вот совокупное применение этих практик, да, это залог грамотной декомпозиции на микросервиса.

И давайте подведём итоги, да, первый тезис, да, что менее связанные микросервисы легче масштабировать, развивать и поддерживать, да, это факт, да, когда у вас всё связано, очень сложно масштабировать, очень сложно поддерживать. Декомпозиция на микросервис должна происходить либо по субдомей, либо по бавным контекстам, да, потому что субдомейн банко контекст - это вот те самые а вещи, да, которые изначально по своей природе слабо связаны. Поэтому, если мы будем на них основывать декомпозицию на микросервиса, мы получим ту самую слабую связь. А микросервисы на событиях, э, менее связаны, да, поэтому потому что синхронный вызов, он в момент вызова склеивает по сути два сервиса. Если один не работает, то другой тоже не работает. Лучше применять события. А найти, да, верные границы сервисов можно только после анализа процессов, да? То есть, если вы не понимаете, как устроен процесс, и при этом уже бросились нарезать на сервисы, то, поверьте, вы их разобьёте неправильно. Сначала нужно понять, как устрим процесс, а уже потом принимать решение. И методика для анализа этих процессов. А их много, да, но вот на сегодняшний день популярно это ванштоминг, да, в силу своей простоты, лёгкого понимания, ну и низкого порога входа для всех участников, да, то есть не обязательно айтишников, мы можем и бизнес захватить, потому что без бизнеса здесь его проводить достаточно неэффективно. Вот поэтому проанализировать процессы и найти границы сервисов можно с помощью практики AVНРИНГ.

И здесь это последний слайд, да, в этой презентации. Здесь я приложил несколько ссылок, да, хочу сказать, что если вас заинтересовали практики, связанные с микросервисами, то как раз у меня есть курс по микросервис архитектуре, где целый модуль мы проводимшторминг в домашнем заданиям, то есть вы сами это всё дело прорабатываете. принимаете решение, а, проводите воркшоп, да, вы выступаете в роли бизнеса и в роли того, кто это веншториминг проводит. В общем, производите декомпозицию системы на основе данной практики. Ну и также мы там разбираем все паттерны микросервисной архитектуры и ещё разбираем, а, 18 антипаттернов, да, то есть как делать не надо. Ну, а если присутствуют разработчики, то есть материалы по тактическому DDD, по чистой архитектуре. И вот именно как внутри сервиса выстроить эту доменную модель. сформировать агрегаты и доменные события. Ну и также здесь несколько статей, да, про а то, как строить а архитектуры, построенные на событиях. И на текущий момент, да, я готов ответить на ваши вопросы по всем тем темам, которые мы с вами сегодня обсудили. Кирилл, спасибо тебе большое. Очень много ты рассказал полезного про DDD и eventтшторминг. У нас есть очень много вопросов. На все мы явно не успеем ответить голосом, поэтому я тебя попрошу потом ответить письменно. И у нас есть конкурс на лучший вопрос. Ээ выбери его, пожалуйста, и мы тогда отправим, э, лучшему вопросу, автору лучшего вопроса уточку, наш приз. Но давай зачитаю хотя бы один вопрос. первый, ательи, а на схеме агрегатов статус - это отдельная сущность или всё-таки объект значения? Может ли атрибуты нам быть объектом значением или это всегда сущность? А здесь зависит от ситуации, да? То есть можно и так, и так делать. А если у статуса только одно значение, допустим, там, ну, условно, там, свободен, занят, назначен на заказ, то лучше сделать как object. Если же там много разных параметров, ну, допустим, есть, ну, нем, а статус, допустим, период доставки, там есть ID, название, дата начала, дата конца, но это всё равно список. Вот здесь его уже делать как обк, ну, не совсем правильно, да, лучше сделать его как тити и потом, а, сделать, скажем так, его дочерней сущности для агрегата. То есть ответ, если в статусе больше, чем одно поле внутри, то лучше делать тити. Если одно поле, то лучше сделать как W object. Угу. Спасибо. И давай ещё один вопросик успеем разобрать. А, от Кати вопрос. Кто должен, кто должен как минимум участвовать в ивентрминге, какие роли и кто обычно лидирует воркшоп с ивентрмингом. Нужна липо подготовка перед воркшопом? Если да, то кто её проводит и как? Угу. Хороший вопрос, да? Смотрите, кто участвует. Аа я на практике собираю не больше 10 человек, да, потому что чем их больше, тем вам сложнее будет их фасилитировать. И есть риск, что они, ну, не примут подход. и отвалятся и скажут, что это вообще-то как это что-то непонятное. Поэтому выберите такое количество людей, которые вам комфортно будет ими управлять, фасилитировать. Поначалу это может быть пять-шесть, да, так в целом до десяти можно. Обязательно э люди от бизнеса, то есть самый вот такой антипатом проведения ваншторминг - это когда аналитики и разработчики вместе собрались и что-то там разрисовали, да? Ну, как бы не мы владельцы этого процесса, да, не мы думаем, как этот процесс должен выглядеть, да, это вот где-то там ребята от бизнеса продумывают, да, какие у нас должны быть там, а, customer j mapap, да, то есть как там юзер должен идти из точки А в точку Б, и они это знают. Наша задача - это просто найти составляющую наложить, а, поэтому обязательно должны быть люди от бизнеса, которые нам должны это всё дело рассказать, как это как это выглядит с точки зрения вот клиента. обязательно сама команда, которая это будет реализовывать, потому что если вы это проведёте, а потом команде просто сбросите, она скажут: "Ну а мы не согласны". А когда там и команда, и бизнес, они с друг с другом коммуницируют, у них больше доверия возникает друг другу. И когда решение будет принято, что мы сервис вот так нарезаем, и те, и другие будут с этим решением согласны. Вам не нужно будет потом ходить и продавать всем. Вот кто фасилитирует, можете вы фасилитировать. То есть в целом тот человек, у которого есть какой-то опыт в проведении или там базовые навыки, он его может его фасилитировать. Это может быть кто угодно: разработчик, аналитик, архитектор. Вот. Фасилитатор - это, по сути, ведущий. Он просто всем подсказывает, как устроена нотация, что мы делаем, когда делаем, а на какой этап переходим и так далее. Нужно просто знать, как проводить процесс. А кто кто угодно может его проводить. Вот, вроде бы на все вопросы ответил. Вот касательно этой части, да, спасибо большое. От тебя тоже добавлю, что очень ценно, когда бизнес разговаривает друг с другом. Довольно много всего интересного, в том числе для них, открывается. Да. А так, Кирилл, тогда я попрошу нам поделиться презентацией и ответить на остальные вопросы уже в чате в Телеграме. А, спасибо тебе огромное. Жаль, что здесь нельзя добавить звук аплодисментов, но уверена, что он бы здесь присутствовал. Вот. А мы готовимся уже к следующему докладу. Всем спасибо. Всем пока. Пока.