Успешная сессия Event Storming - как и успешный программный проект - требует в равной степени искусства, знаний и технических навыков. Кроме того, гораздо дешевле вносить изменения в стикеры, чем в производственный код. Изучение ваших систем путем написания кода - очень дорогой способ понять и усовершенствовать задействованные бизнес-процессы.

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

Что такое реактивная система?

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

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

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

Это возможно, потому что в системном домене, управляемом событиями, события публикуются в журнале. Любая другая система в вашей организации, имеющая доступ к журналу, может подписаться на опубликованные события и реагировать на эти события в режиме реального времени. Самое интересное в этом методе - его простота; предприятия веками работали из журналов. Мы просто переносим этот метод в современный контекст.

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

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

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

Теперь все, что нам нужно, - это современная техника, которая поможет нам моделировать такие системы.

Событие Штурм

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

Мастерская

Провести семинар по Event Storming просто: участники системы входят в комнату с неограниченной поверхностью для моделирования - гигантским листом бумаги, приклеенным к стене, - и наклеивают на нее стикеры. Звучит просто? Это. Это радость Event Storming; он фокусируется исключительно на текущей задаче, а именно на понимании ваших бизнес-процессов, без всяких церемоний, связанных с чрезмерно сложными методами моделирования, которые мешают общению.

Не так быстро. Нам нужно следовать ряду правил, чтобы не попасть в хаос. Ценность Event Storming - это общение, а не просто приклеивание стикеров к стене.

Теперь мы познакомим вас с основными концепциями, используемыми при обсуждении и моделировании бизнес-процессов, управляемых событиями, - событиями, реакциями и командами.

Что такое событие?

Во-первых, мы начнем думать о наших бизнес-процессах исключительно с точки зрения событий и реакций, что является причудливым способом сказать «причинно-следственная связь».

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

- Мартин Фаулер, Событие предметной области »

Мы можем перефразировать цитату Мартина следующим образом:

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

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

Потоки событий

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

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

Что такое реакция?

Реакция - это то, что должно произойти после того, как произойдет что-то еще. Реакции лучше всего отражены в следующем утверждении:

«Это происходит всякий раз, когда это происходит».

Это реакция. Это событие. Каждый раз - это слово, которое связывает событие с реакцией на создание политики.

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

«Каждый раз, когда создается новая учетная запись пользователя, мы отправляем ей подтверждение по электронной почте».

Если вы прочитаете приведенное выше утверждение, ключ кроется в напряжении. События всегда проходят в прошедшем времени, а реакции - в будущем. Что еще более важно, мы никогда не обсуждаем «сейчас» - мы не можем делать какие-либо предположения о текущем состоянии системы, потому что нет гарантии, что то, что мы намереваемся сделать, действительно произойдет. Ошибочные предположения являются основной причиной большинства сбоев в компьютерных системах. Моделируя только причинно-следственные связи, мы можем лучше решить, как реагировать на что угодно, потому что мы не делаем ложных предположений о результатах - не только об успешных результатах, но также об ошибках и прочем -идеальные события.

Что такое политика?

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

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

Мы также видим, что реакции часто вызывают новые события, такие как «разветвление» реакций; разветвление - это когда два или более эффекта возникают с другой стороны того, вызвавшего эти эффекты. Все системы, управляемые событиями, основаны на причинно-следственных связях, поэтому важно уловить как можно больше эффектов. Событие, которое вызывает разветвление таким образом, вероятно, заслуживает более глубокого погружения, возможно, даже достойного отдельного сеанса штурма событий.

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

Теперь, когда мы знаем, что события могут вызывать множественные реакции, и эти реакции могут вызывать новые события. Что еще может вызвать события?

  • Внешние системы (розовые липучки)
  • Команды (синие стикеры)
  • Команды, инициированные пользователем (синие стикеры с аннотацией человека)

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

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

  • Какую информацию нам нужно получить от пользователя?
  • Какую информацию мы включаем в событие кредитной карты?
  • Каковы детали платежного процессора и как он взаимодействует с внешней системой?

Есть еще несколько интересных элементов, которые мы можем использовать в наших потоках:

  • Таймеры (оранжевые стикеры с часами)
  • Планировщики (оранжевые стикеры с календарем)

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

Что такое команда?

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

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

  • Требования к пользовательскому интерфейсу
  • Модели данных
  • Так далее

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

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

Самый эффективный способ определить структуру в системе, управляемой событиями, - это использовать технику Domain-Driven Design.

Далее мы рассмотрим основы предметно-ориентированного проектирования и то, как несколько ключевых строительных блоков могут помочь нам структурировать наши потоки.

Домен-ориентированный дизайн

Там, где сеанс Event Storming можно использовать для моделирования потоков бизнес-процессов, Domain-Driven Design обеспечивает дисциплину, позволяющую превратить эти потоки в структурированную систему. Когда мы упоминаем систему, мы не имеем в виду автоматически код, мы просто имеем в виду «систему» ​​в самом чистом смысле этого слова, независимо от того, является ли эта система ручной или автоматизированной.

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

- Альберто Брандолини, Event Storming

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

Представьте себе обычный сценарий, в котором вы пытаетесь смоделировать поток бизнес-процессов, охватывающий команды и даже отделы большой корпорации ...

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

Чтобы структурировать наши потоки, мы сосредоточимся на двух основных элементах DDD - агрегатах и ограниченных контекстах.

Что такое агрегат?

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

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

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

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

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

Что произойдет, если я изменю строку кода в модуле доставки; это нарушит выплаты?

Агрегаты привносят структуру в наш дизайн, изолируя связанные проблемы друг от друга.

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

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

Что такое ограниченный контекст?

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

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

Определяя ограниченные контексты, мы можем начать понимать, как взаимодействуют субдомены системы, не погружаясь в глубину кода. Система доставки может быть устаревшим приложением J2EE, Платежная система может быть современной системой, построенной на Akka, но они общаются друг с другом исключительно в событиях.

Заключение

Event Storming - это совместное упражнение, которое не знает названий должностей или иерархии, важны только идеи, но в реальном мире лица, принимающие решения, должны чувствовать себя комфортно, продвигая упражнение вперед с действием. Модели - это побочный продукт разговоров, и именно эти разговоры имеют реальную ценность. Расширение коммуникации будет иметь волновой эффект во всей организации. Модели можно использовать в качестве действенных схем для разработки программного обеспечения, но их также можно использовать просто как инструмент для улучшения потока коммуникации. Когда чертежи используются для создания программного обеспечения, результатом является код, отражающий язык и структуру бизнеса. Затем межфункциональные группы могут обсуждать и рассуждать о коде, используя тот же язык и модели, что и бизнес, обеспечивая эффективное и точное сотрудничество в будущем.

Учить больше

Я настоятельно рекомендую следующие ресурсы, чтобы узнать больше о Event Storming и Domain-Driven Design:

  • Event Storming Альберто Брандолини - это предварительная книга, написанная самим создателем Event Storming, и она должна стать основополагающим текстом по методам, описанным в этой статье.
  • Domain-Driven Design Distilled Вона Вернона - лучшее краткое введение в DDD, доступное в настоящее время. Я имел удовольствие проводить семинар по штурму событий с Воном, и его уровень понимания того, как моделировать системы, управляемые событиями, не имеет себе равных.
  • Доменно-ориентированный дизайн: преодоление сложности в основе программного обеспечения Эрика Эванса - это основополагающий текст DDD. Это нетривиальное чтение, но для архитекторов программного обеспечения, желающих глубже погрузиться в моделирование современных систем, оно должно быть в верхней части списка для чтения.

Об авторе

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

До того, как стать соучредителем RedElastic, он был архитектором предприятия в Lightbend, корпоративном ответственном за язык программирования Scala вместе с Play и Akka.

В свободное время он организует ReactiveTO, ведущую группу встреч по реактивному программированию в Торонто.