Чем полезен Event Storming при проектировании приложения

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

 

Проблематика

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

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

В результате код становится сложным, и разобраться в нем оказывается тяжело. Для примера можно посмотреть на проект, выполненный на фреймворке laravel. Структура папок не кажется сложной, однако она не отражает логику приложения. По ней нельзя понять, какие функции оно выполняет.

Ситуацию хорошо иллюстрирует шуточная картинка, которую вы уже могли встречать на просторах интернета.

 

Что такое Event Storming

Event Storming — это способ исследовать сложную предметную область бизнеса, но сделать это без больших временных затрат. При этом над задачей совместно будут работать и разработчики, и бизнес-эксперты. Такой подход обеспечивает специалистам разных профилей взаимопонимание.

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

 

Как использовать подход

Event Storming начинается с описания системы. Сначала нужно определить главную цель и выделить событие, наклеить на доску соответствующий стикер как правило оранжевого цвета. То есть процесс построения структуры идет от обратного. В случае с интернет-магазином целью является конкретное событие — оформление заказа. Оно подразумевает под собой покупку клиентом товара, и получение бизнесом прибыли. Значит, именно такой стикер и должен оказаться на доске.

Далее нужно выделить сущность, модель или агрегат (Агрегат это понятие из DDD). Так называется объект, с которым происходит выделенное на предыдущем этапе событие. В нашем случае сущность — это заказ, желтый стикер.

Далее нужно добавить стикер с процессом, который приводит к выделенному ранее событию. Он называется команда. В нашем примере это процесс оформления заказа, синего цвета.

Дополнительно, если это будет полезно, вешаются информационные стикеры. На них указываются данные, необходимые для выполнения события. В нашем примере требуется информация о товарах из корзины и адресе доставки. Эти данные нужны для оформления заказа.

Конечно, в реальности информации потребуется больше, но для понимания подхода и сути Event Storming этого будет достаточно.

Сформированная группа стикеров называется бизнес-правилом.  Далее нужно создать другие группы, описывающие предыдущий этап процесса (ведь мы идем от обратного). В нашем случае, для оформления заказа перед этим должно случиться другое событие — добавление товара в корзину. Значит, оно должно стать отдельным бизнес-правилом.

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

Далее собранные группы объединяются в ограниченные контексты. Это позволяет поручать работу с определенным контекстом конкретной группе разработчиков компании. 

В качестве протоколов взаимодействия между собранными контекстами могут применяться REST и RabbitMQ. Контексты позволяют понять, какие микросервисы можно выделить и развивать как отдельные системы. Также код можно разделить на пакеты, которые будут взаимодействовать друг с другом, но при этом будут иметь малое количество связей, что сделает их менее зависимыми.

 

Пример кода

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

Так может выглядеть уровень представления, реализованный в REST API — все наглядно и понятно:

class CartController extends AppController
{
    public function addProduct(int $productId): void
    {
        if (!$cart = $this->cartRepository->findByUserId($this->authUser->getId())) {
            return $this->createForbiddenResponse();
        }
        if (!$product = $this->productRepository->findById($productId)) {
            return $this->createNotFoundResponse();
        }
        //commandBus
        $this->commandBus->handle(new AddProductInCartCommand($product, $cart));
        //eventBus
        $this->eventBus->handle(new ProductAddedInCartEvent($product, $cart));
        return $this->createNotContentResponse();
    }
}

Вся структура кода становится читаемой, и отображает бизнес-логику. Можно сразу понять, как происходит процесс покупки товара в интернет-магазине.

 

В качестве заключения

Таким образом, Event Storming позволяет:

1. Выявить события и команды.

2. Определить границы, выделив контексты.

3. Конкретизировать передаваемую информацию.

4. Сформировать бизнес-логику.

5. Трансформировать бизнес-логику в код.

Это не только упрощает написание кода и разработку приложения, но и облегчает его дальнейшую поддержку. Даже если команда разработки полностью сменится, ей не составит труда разобраться в работе предшественников.

Поэтому Event Storming — мощный, полезный инструмент, обеспечивающий прозрачную и понятную бизнес-логику, и ее трансформацию в легко читаемый код.