Три маркера границ контекста (микросервисов) в Event Storming

О методологии Event Storming часто говорят как о хорошем помощнике в нелегком деле обнаружения границ микросервисов. Но что значит - «хороший помощник»? Неужели в готовом артефакте загораются красные стрелочки и через весь экран бежит надпись «Вот он, родимый. Тут начинается, а тут заканчивается. Хватай его пока не смылся!» Не хочу вас расстраивать, но ничего подобного я там никогда не наблюдала. 

И все же метод Альберто Брадолини действительно помогает. Для себя я выделила три (пока только три) приметы, которые сообщают, что граница какого-то контекста (возможно, целого сервиса) точно проходит здесь. Сейчас расскажу. 

Смена именования

Эта статья предполагает, что вы уже знакомы с методологией и активно её практикуете. Но данный способ подойдет даже для тех, кто ничего про Шторминг событий не знает. 

Наверняка вы сталкивались с ситуациями, когда один и тоже объект называется по-разному. Так например, если кто-то сказал про подъезд – парадная, значит человек из Санкт-Петербурга, либо ты сам прямо сейчас в Питере. 

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

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

Представьте, что существует некая организация, которая помогает фрилансерам и заказчикам находить друг друга. Сначала она берет на работу фрилансеров, а потом продает их услуги своим клиентам. Это кейс, который Екатерина Пантелей приготовила для своего воркшопа по Event Storming. Мне повезло быть на тестовом прогоне. Екатерина постаралась и описала процессы в художественной форме, которая не терпит тавтологий. 

Читая кейс в первый раз я очень быстро запуталась в том, кто кому клиент и где там заказчик. Всего три участника, а названий шесть: клиент, заказчик, фрилансер, кандидат, исполнитель, компания. Конечно, на воркшопе кейс был представлен в такой форме, которая исключила надопонимания. Вы не были на нем? А можете предположить в какой момент кандидат превращается в исполнителя? Ура! Вы обнаружили границу контекста. Для этого даже не нужно выстраивать события. Но на примере событий получается наглядней. 

Разрыв в логике повествования

После того, как цепочка событий построена наступает этап проверки методом прямого и обратного чтения. Почему-то его никто не любит и обычно пропускают. А для меня проверка – основной инструмент обнаружения границ.

Поговорим о процессе платежей. Что там происходит? Я предполагаю, что случается всё примерно вот так:

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

Давайте попробуем прочесть эту цепочку дальше:

Когда запрос на списание создан, запрос обработан – логично. 

Когда запрос обработан, запрос выполнен – нормально (пока не рассматриваем альтернативные сценарии) . 

Когда деньги со счета списаны, уведомление о списании отправлено – вроде бы да. Но что если пользователь не разрешил присылать себе уведомление? Дальше еще интереснее. 

Когда уведомление о списании отправлено, деньги на счет зачислены. Что?!!! 

Кажется между стикером с событием уведомления и следующим логика покинула процесс. Ура! Мы нашли границу контекста. 

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

Как проверить, с чем мы имеем дело: с ошибкой или с границей? Убрать событие, на котором споткнулись, из цепочки. Если процесс ломается, ищем что мы упустили. Если процесс продолжает существовать, значит событие в цепочке из другого процесса. 

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

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

А что с первым стикером про авторизацию? Могут ли платежи осуществляться без этого? Да, если мы найдем способ явным образом указать что откуда списывается, куда зачисляется и будем уверены в том, что исполняем волю владельца денег. Авторизация нужна нам. Но если есть способ осуществить функцию авторизации другим способом, то – нет. Контекст авторизации выделенный и тоже автономный. Он одинков не только для процессов осуществления платежей, но и для других: запрос выписки по счету, проверка баланса и т.п. Чем не микросервис?

Смена агрегата

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

Клиент оставляет заказ в сервисе службы такси. Водитель принимает и исполняет заказ. Один и тот же заказ для клиента и исполнителя. Но так ли это? 

Какая информация о заказе важна для клиента? Готов ли кто-то его отвезти, на какой машине, как долго ждать подачу, сколько будет стоить поездка – всё вот это вот. 

У водителя другие вопросы к заказу: сколько километров ехать, сколько времени займет, в каком районе придется ждать следующий заказ и сколько он на этом может заработать. 

Процессе участвует третья сторона – агрегатор, которого интересует кто оставил заказ, кто исполнил, каким образом была осуществлена оплата, сколько и кому от этой суммы нужно отдать и сколько останется самому агрегатору. 

Один заказ – три контекста, которые на сессии Event Storming обнаруживаться, скорее всего, только на этапе добавления стикеров Aggregate. Тем не менее, мы это увидим. Поэтому я записала смену агрегата как маркер возможной границы микросервиса. 

Резюме

Вот мои три приметы, указывающие на возможные границы микросервисов:

• смена именования;
• разрыв в логике повествования;
• смена агрегата. 

Что-то из этого можно применять без Event Storming хоть и сложно будет без визуализации модели процесса хоть в какой-то форме. Для приметы номер два все же придется сделать первый этап методологии - Big Picture. Но затраченные усилия обычно окупаются. 

Есть ли у вас свои способы обнаружить границы микросервисов? Поделитесь опытом.