Event Modeling — это метод описания информационных систем на основе анализа изменений информации с течением времени. В частности, опускаются временные детали и выделяется то, что хранится долговременно, и что пользователь видит в любой конкретный момент времени. Это события на временной шкале, формирующие описание системы.
Проблема автоматизации, особенно нетривиальных систем, заключается в возрастающей кривой затрат на дальнейшие изменения по мере усложнения системы. Большая часть этих дополнительных затрат на автоматизацию связана с доработкой (показаны красными прямоугольниками ниже). Event Modeling сводит к минимуму объем переделок за счет разработки плана проекта, который может быть создан за очень короткое время по сравнению с существующими методологиями проектирования и моделирования.
История создания
Метод Event Modeling был придуман Адамом Димитруком на основе спецификаций долгоживущих процессов, которые Грег Янг использовал в системах CQRS/ES. В результате интеграции метода Альберто Брандолини Event Storming, получился формат воркшопа.
Название Event Modeling появилось после саммита Event Storming в июле 2018 года в Болонье, Италия.
Тогда было очевидно, что Event Storming и Event Modeling значительно различаются. В то время как Event Storming фокусируется пространстве задач, Event Modeling создает план решения. Поскольку Event Modeling не занимает много времени, он также может выступать в качестве упражнения по исследованию пространства задач, пробуя различные решения.
Основные идеи и подходы
Временная шкала
Время — это концепция, которая является основной частью описания системы. Компоненты и классы, которым мы привыкли, не так важны. Мы можем выразить, что система должна делать от начала до конца, на временной шкале без разветвлений. Отслеживаются все значения полей пользовательского интерфейса до их попадания в хранилища данных, где они, наконец, используются для последующего отображения в пользовательском интерфейсе. Обычно это делается с помощью стикеров на стене или доске. Мы увидим, что в основе подхода лежит простота, поскольку мы будем использовать только 3 типа строительных блоков, а также традиционные каркасы или макеты. Далее, чтобы упростить задачу, мы будем полагаться только на 4 шаблона того, как мы структурируем диаграмму.
Простота
Если команда выбирает инструмент под названием X, а для X требуется целая книга и семинар, на который уходит неделя, это сводит на нет эффективность X, и это главный недостаток, независимо от того, насколько хорош Х. Когда книга обязательна к прочтению людьми в организации, все скажут, что читали ее; только половина прочитает половина из них заявит, что поняла содержимое; и только половина из них поймет; и половина из них сможет применить на практике. Вот почему Event Modeling использует только три строительных блока и четыре шаблона, основанных на двух идеях. Объяснение занимает несколько минут, а остальная часть обучения выполняется на практике, прозрачно, где любые недостатки в понимании даже этих нескольких основных идей быстро исправляются. Так налаживается коммуникация в команде.
События
Допустим, мы хотим разработать веб-сайт отеля для гостиничной сети, чтобы наши клиенты могли бронировать номера онлайн, а мы могли планировать уборку и любые другие действия, связанные с отелем. Мы можем показать, какие события или факты хранятся на временной шкале года в этом бизнесе в течении. Мы можем допустить, что у нас уже есть система, и спросить себя, какие факты были сохранены, когда мы продвигались вперед во времени.
Каркасы
Чтобы задействовать визуальную часть повествования, мы размещаем каркасы или макеты веб-страниц сверху. Они могут быть организованы в виде плавательных дорожек, чтобы показать разных акторов, взаимодействующих с нашей системой. Мы также показываем здесь любую автоматизацию с помощью символа типа шестерёнки, чтобы проиллюстрировать, что система что-то делает. Это имеет простой для понимания набор механизмов списка задач, которые выполняет процесс и помечает элементы как выполненные. В нашем примере с отелем это может быть платежная система или система уведомлений
На данный момент у нас есть достаточно, чтобы иметь возможность проектировать некоторые системы со специалистами по UX/UI. Но есть два очень фундаментальных элемента, которые должны быть добавлены в проект, которые показывают две основные функции любой информационной системы: расширение прав и возможностей пользователя и информирование пользователя.
Команды
Большинство информационных систем должны предоставлять пользователю возможность влиять на состояние системы. В нашем примере мы должны разрешить при бронировании номера изменить систему, чтобы мы не перепроверяли бронирование, и когда этот человек прибудет в указанною дату, для него будет готов номер.
Намерения изменить систему инкапсулируются в команды. В отличие от простого сохранения данных формы в таблицу в базе данных, команды позволяет нам иметь нетехнический способ показать намерения, допуская при этом различные реализации.
С точки зрения пользовательского UI и UX это приводит к интерфейсу, основанному на командах, который помогает создавать компонуемые пользовательские интерфейсы. С этим шаблоном намного яснее границы транзакций как с технической, так и с бизнес-перспективы. Гость отеля либо успешно зарегистрировался, либо нет.
Когда есть нюансы в отношении того, какие предпосылки необходимы для успешного выполнения команды, они уточняются в спецификациях в стиле «Given-When-Then». Это, опять же, способ рассказать историю о том, как выглядит завершенность выполнения команды. Может быть несколько таких историй, чтобы показать, как команда может и не может успешно выполнена.
Примером может быть “Дано: Мы зарегистрировались и добавили способ оплаты, Когда: Мы пытаемся забронировать номер, Затем: номер забронирован”. Эта форма спецификации также называется Arrange, Act, Assert, а в мире UX/UI - Situation, Motivation, Value.
Представления (Read Models)
Вторая часть любой информационной системы - это возможность информировать пользователя о состоянии системы. Гость нашего отеля должен знать о том, какие дни доступны для определенных типов номеров, в которых он хочет остановиться.
Представление о фактах, уже имеющихся в системе, менялось по мере сохранения этих новых событий. В нашей гостиничной системе это представление календаря обновлялось по мере появления новых событий, влияющих на инвентарь. Другие Views могут быть предназначены для того, чтобы персонал по уборке мог видеть, какие номера готовы к уборке, поскольку сохраняются события о выезде гостей.
Определение того, как ведет себя Views, очень похоже на то, как мы определяем, как мы принимаем команды, с одним отличием. Views являются пассивными и не могут отклонить событие после того, как оно было сохранено в системе. У нас есть “Указано: отель рассчитан на 12 номеров с видом на океан, номер с видом на океан был забронирован с 4 по 12 апреля X 12, Затем: в календаре должны быть указаны все даты, кроме 4-12 апреля, для наличия свободных номеров с видом на океан”.
Интеграции
Мы только что рассмотрели первые два шаблона из четырех, необходимых для описания большинства систем. Системы могут получать информацию от других систем и отправлять информацию другим системам. Было бы заманчиво заставить эти два шаблона быть расширением первых двух и использовать одно и то же пространство. Однако эти взаимодействия труднее передать, поскольку они не имеют видимого для человека аспекта и требуют некоторых шаблонов более высокого уровня.
Переводы
Когда у нас есть внешняя система, которая предоставляет нам информацию, полезно преобразовать эту информацию в форму, которая более привычна в нашей собственной системе. В нашей гостиничной системе мы можем получать информацию о событиях по GPS-координатам гостей, если они подписались на нашу быстро реагирующую команду по уборке. Мы не хотели бы использовать пары долготы и широты в качестве событий для указания предварительных условий в нашей системе. Мы бы предпочли события, которые что-то для нас значат, например, «Гость покинул отель», «Гость вернулся в номер отеля».
Часто переводы достаточно просты, чтобы их можно было представить в виде представлений, получающих информацию из внешних событий. Если мы не используем их как какие-либо части тестов «данные», значения, которые они хранят в этой модели представления, просто представлены в параметрах команды в наших тестах изменения состояния.
Автоматизация
Наша система должна будет взаимодействовать с внешними службами. Когда гости в нашем отеле оплачивают свое проживание при выезде, наша система вызывает обработчик платежей. Мы можем составить представление о том, как это происходит, используя идею “списка задач” для некоторого процессора в нашей системе. Этот список задач показывает задачи, которые нам нужно выполнить. Наш процессор время от времени просматривает этот список и отправляет команду во внешнюю систему для обработки платежа, например. Затем ответ от внешней системы преобразуется в событие, которое мы сохраняем обратно в нашей системе. Таким образом, мы сохраняем строительные блоки, которые мы используем в нашей системе, как нечто значимое для нас.
Мы показываем это, помещая процесс обработки платежа в верхнюю часть нашего чертежа с каркасами. Это показывает, что есть вещи, которые не очевидны на экране, но происходят за кулисами. Пользователь может ожидать, что вращающийся значок указывает на задержку из-за необходимости завершения фоновых задач. Спецификация для этого имеет форму «Дано: представление задач, которые необходимо выполнить, Когда эта команда запускается для каждого элемента, Затем ожидаются эти события».
Формат сессии
Event Modeling выполняется в 7 шагов. Итак, давайте вернемся к началу и посмотрим, как создать план проекта:
1. Мозговой штурм
У нас есть кто-то, кто объяснит цели проекта и другую информацию. Затем участники представляют, как будет выглядеть и вести себя система. Они записывают все события, которые, по их мнению, произошли. Здесь мы осторожно вводим концепцию, согласно которой должны быть указаны только события, изменяющие состояние. Часто люди называют «гостевой календарь доступности номеров». Мы пока откладываем их в сторону - это не события.
2. История
Теперь задача состоит в том, чтобы создать правдоподобную историю из этих событий. Таким образом, они расположены в линию, и каждый просматривает эту временную шкалу, чтобы понять, что это имеет смысл, поскольку события происходят по порядку.
3. Раскадровка
Далее, каркасы или макеты истории необходимы для визуального анализа. Что еще более важно, каждое поле должно быть представлено таким образом, чтобы схема системы имела источник и назначение информации, представленной с точки зрения пользователя.
3.1 UX и многопользовательский доступ
Каркасы обычно размещаются в верхней части чертежа. Их можно разделить на отдельные дорожки, чтобы показать, что видит каждый пользователь, если их несколько. Нет экранов, которые появляются друг над другом, так как нам нужно фиксировать каждое изменение в состоянии системы как отдельный вертикальный срез схемы. Различный порядок может быть показан в различных спецификациях. Если это является ядром системы или очень важно для коммуникации, необходимо будет добавить в план альтернативные рабочие процессы. Это часть последнего шага, который демонстрирует организованность, но его можно сделать раньше, если это будет полезно.
4. Определение источников данных
Теперь мы должны связать информацию, накопленную путем хранения событий, c пользовательским интерфейсом с помощью представлений (Read Models). Например, это может быть просмотром календаря в нашей гостиничной системе, который показывает наличие свободных номеров, когда пользователь хочет забронировать номер.
6. Применение закона Конвея
Теперь, когда мы знаем, как информация проходит через нашу систему, мы можем приступить к организации самих событий в виде плавательных дорожек. Нам нужно сделать это, чтобы позволить системе существовать как набор автономных частей, с которыми могут работать отдельные команды. Это позволяет специализации происходить на уровне, который мы контролируем, а не выпадать из состава команд.
7. Проработка сценариев
Каждый шаг рабочего процесса привязан либо к команде, либо к представлению. То, как мы их создаем, по-прежнему зависит от сотрудничества со всеми участниками. Предложения Give-When-Then или Given-Then могут быть построены одно за другим очень быстро, пока они рассматриваются несколькими ролями. Совместная работа над сценариями пользователей с помощью визуальных средств, требует меньше временных затрат, чем традиционное написание пользовательских историй. Что здесь очень важно, так это то, что каждая спецификация привязана ровно к одной команде или представлению.
Проверка завершенности
В это время в модели событий должно быть учтено каждое поле. Вся информация должна иметь источник и пункт назначения. События должны способствовать этому переходу и содержать необходимые для этого поля. Такая строгость требуется для получения максимальной отдачи от метода.
Альтернативные вариант заключается в том, что мы не проводим эту окончательную проверку и полагаемся на покрытие затрат за счет переделок. Бывают случаи, в которых это более предпочтительно.
Управление проектом
Конечным результатом является набор небольших проектов, определенных всеми сценариями для каждого шага рабочего процесса. Они представлены в формате, который позволяет напрямую переводить их в модульные тесты. Они также связаны со смежными шагами рабочего процесса только контрактами.
Строгие контракты
Многие с управления проектами, бизнеса и координации смягчаются тем фактом, что мы заключаем строгие контракты в отношении формата данных при начале и конце определенных шагов рабочего процесса. Эти предварительные и последующие условия позволяют завершить работу в относительной изоляции, а затем соединить ее с соседними этапами, как это было задумано.
Плоская кривая затрат
Самым большим эффектом использования Event Modeling является плоская кривая средней стоимости реализуемой функциональности. Это связано с тем фактом, что на усилия по построению каждого шага рабочего процесса не влияет разработка соседних рабочих процессов. Одна важная особенность, которую следует понимать, заключается в том, что шаг рабочего процесса считается повторяющимся в модели событий, если в нем используется одна и та же команда или представление.
Что сделано, то сделано
Когда выполняется шаг рабочего процесса, выполнение любого другого шага рабочего процесса не вызывает необходимости возвращаться к этому уже завершенному шагу рабочего процесса. Именно по этой причине может быть реализована постоянная кривая стоимости функций.
Эстимейты без Эстимейтов
При постоянной кривой затрат, усилия по внедрению могут быть просто измерены по количеству функциональности с течением времени. Это беспристрастный способ эмпирически определить скорость команд. Эти показатели затем используются для определения масштабов, планирования и расчета стоимости будущих проектов.
Примечание о разработке через тестирование
Влияние Agile в индустрии, позволяющее скрыть проблемы отсутствия проектирования, привносит необходимость в покрытии тестами. Поскольку объем каждого набора требований теперь относится к шагу рабочего процесса, шаг рефакторинга TDD не влияет на другие шаги рабочего процесса в Event Modeling. При отсутствии событийной модели, рефакторинг проходит вне ограниченного контекста, что может сломать ранее реализованные части. Чем больше работы уже выполнено, тем больше приходится пересматривать и корректировать с каждым новым дополнением по мере реализации.
Аутсорс
Кривая постоянных затрат дает возможность выполнять проекты с фиксированными затратами. Как только для команды выявлена скорость, у вас появляется оценка стоимости программного обеспечения. Теперь помощью этих показателей можно оценить, сколько вы готовы потратить на подрядчиков за каждый этап работ, который они выполняют.
Приоритеты
Перемещение работ по графику в отношении того, какие шаги будут выполняться в первую очередь, выполняется без изменения сметных затрат по каждому пункту. Это гарантирует, что приоритезация работ не повлияет и на их общую стоимость. Кривая постоянных затрат необходима, чтобы обеспечить «гибкость» перераспределения функциональности.
Управление изменениями
Когда планы меняются, мы просто корректируем событийную модель. Обычно это делается путем простого копирования и корректировки. Теперь мы можем видеть, в чем заключаются различия. Если к одному событию добавляется новая часть информации, это составляет новую версию рабочего процесса. То же и с представлениями. Если они еще не реализованы, они не меняют нашу оценку. Если они уже реализованы, они добавляют в наш план еще одну единицу работы. По этому поводу есть еще несколько правил. Конечным результатом является исчерпывающее руководство по управлению изменениями.
Безопасность
Событийная модель точно показывает потоки данных, это важно, когда конфиденциальные данные пересекают границы. При проведении традиционных аудитов, интервью с персоналом отнимало много времени и приводило к риску упустить важные моменты. Проблемы безопасности решаются наиболее ответственно, когда приложения имеют модель событий на которую можно сослаться.
Легаси Системы
Большинство случаев, с которыми сталкиваются в реальной практике, - это когда система уже существует. Основной способ справиться с системой, которой трудно управлять из-за сложности и непонимания, - это либо переписать ее, либо провести рефакторинг. И то, и другое обходится очень дорого.
Существует третий, менее рискованный вариант: заморозить старую систему. Можно не изменять существующую систему. Исправление ошибок и добавление новых функций выполняются сбоку в качестве дополнительного решения.
События можно собирать из базы данных старой системы и создавать представления этого состояния, используя ранее описанный шаблон перевода. Здесь показан пример, который исправляет ошибку (обратите внимание, что мы используем шаблон внешней интеграции и расширяем старую систему для добавления изображений профиля:
Этот шаблон позволяет перестать вкладывать ресурсы в неоптимальную существующую систему с помощью шаблонов, которые обеспечивает событийная модель.
Заключение
Event Modeling меняет способ построения информационных систем. С простыми повторяемыми шаблонами информационные системы становятся более предсказуемы.
Ссылки
https://www.onote.com - редактор диаграмм, разработанный для данного метода
