Как моделировать бизнес-процессы

Какой способ моделирования бизнес-процессов стоит выбрать, если стоит задача создания цифровой модели бизнеса? Пожалуй, наиболее эффективным является предметно-ориентированный подход (DDD, Domain-Driven Design). Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).

Проектирование (о нем я пишу в своем телеграм-канале) можно разделить на стратегическое и тактическое. Для аналогии, представьте себе процесс написания картины: сперва вы создаете набросок крупными мазками, а затем прорабатываете детали.

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

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

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

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

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

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

За каждым именованным элементом единого языка скрываются связанные с ним концепции. При попытке учесть их все, модель очень быстро превращается в большой ком грязи (big ball of mud). Что следует оставить внутри границ смыслового ядра, а что исключить, поместив за его пределами? Я рекомендую задавать себе следующий вопрос - является ли данная концепция неотъемлемой частью моделируемой предметной области? Если нет - смело выносите наружу. Скорее всего, эти внешние компоненты при их скоплении образуют свои ограниченные контексты, с которыми будет взаимодействовать ваше смысловое ядро.

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

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

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

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

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

Сущность моделирует индивидуальный объект, имеющий уникальную идентичность. Сущность может быть изменчива во времени.

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

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

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

Перечислю наиболее полезные правила проектирования агрегатов:

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

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

Проектирование программного обеспечения всегда ограничено во времени. Время имеет значение и оказывает значительное влияние на наши решения. Наиболее эффективным инструментом для ускорения процессов проектирования является методика cобытийного штурма (event storming).

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

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

Что вам потребуется для событийного штурма?

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

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

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

В процессе событийного штурма, скорее всего, вы обнаружите многочисленные модели и потоки событий предметной области между ними. Приведу некоторые рекомендации по работе с ними:

В заключении стоит упомянуть про представления (views), обеспечивающие пользователям возможность выполнения действий с учетом разных ролей. Представления принято обозначать зелеными стикерами и размещать отдельно. Не стоит отображать все представления. Отображайте наиболее важные. Если будет необходимо отметить, что данное представление должно работать в сочетании с заданной ролью пользователя, создайте желтые стикеры с пиктограммой человека и названием роли, и поместите их рядом с соответствующим представлением.

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

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