Элементы и этапы Event Storming
С прошлого эпизода про Event Driven у нас остался удобный черновик программной системы. Пора по нему построить настоящую диаграмму со всеми элементами Event Storming и узнать про трудности, которые в этом процессе возникают. Потом упростить моделирование большого проекта разделением на удобные этапы на примере службы перевозки грузов:
- 00:00:06 Сложность больших проектов
- 00:01:41 Элементы Event Storming
- 00:02:26 Команды и события
- 00:03:33 Именование агрегата
- 00:04:09 Действующие лица
- 00:05:25 Политики или бизнес-правила
- 00:06:19 Сторонние сервисы
- 00:07:34 Бизнес-процесс смены адреса
- 00:08:11 Сложность придумывания агрегатов
- 00:09:49 Другие события от сервисов
- 00:10:42 Придумывание новой функциональности
- 00:11:08 Вспомогательные данные для интерфейса
- 00:11:51 Проблемы прямого чтения
- 00:12:58 Отдельная модель чтения
- 00:14:43 Параллельный бизнес-процесс
- 00:15:13 Ограниченные контексты
- 00:18:06 Вопросы и примечания
- 00:19:03 Диаграмма Event Storming
- 00:21:03 Проблемы подробного подхода
- 00:23:04 Ускорение моделирования
- 00:25:17 Этапы Event Storming
- 00:27:09 Пример бизнеса доставки грузов
- 00:35:53 Насколько стало лучше
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
Отлично, + за слайды. С нетерпением жду продолжения!
Спасибо!
Возник вопрос по поводу команд. Если одна команда вызывается разными акторами (например, клиентом, админом, системой), то стоит разделить эту команду на три или оставить одну, но через аргументы понимать кто именно её вызвал?
Command не зависит от того, кто её вызывает. По вашей логике ещё нужно будет создать команду для Console, если её вызывает консоль. Так же придётся создать команду для EventHandler, если кто-то будет вызывать и её. По аналогии придётся разделить и Query. А если ещё подумать дальше, то и методы у сущности вам тоже придётся разделять. Тогда в методах появятся префиксы
admin…(),client…()Так что в этом особо смысла нет. Но всё зависит от поведения и набор бизнес правил, политик. Вызов команды клиентом может предусматривать какие-то одни действия, а вызов команды Админом предусматривает какие-то другие действия или другой результат. При этом команды могут даже назваться по-другому.Очень хороший пример может быть система «Auth». В ней Администратор может вызвать команду «сбросить пароль» (
ResetPassword), в которой будет сгенерирован и выслан новый пароль на почту пользователю. А Пользователь вызвав, другую команду «запросить сброс пароля» (RequestResetPassword), должен будет получить ссылку для сброса на почту и, перейдя по этой ссылке, ввести старый и новый пароль, затем вызовется другая команда «подтвердить сброс пароля» (ConfirmResetPassword). Это как пример.Так что тут зависит от того, что делает эта команда. Если для разных акторов это действие отличается, то нужно разносить команды, а пока действие делается одно - можно оставить в одном, общем, месте. Тоже самое и для Query.
Но если ещё глубже копать, то мы можем понять, что у Админа и Клиента вообще могут быть разные контексты, в которых будут лежать свои Command и Query. Тогда делить надо не команды, а все модули. У каждого будут свои сущности, команды, запросы.
Поэтому на этапе EventStorming Вы и должны это всё определить.
Как посоветовали выше лучше разделить по смыслу на отдельные простые команды. Вместо написания одной сложной неудобной команды с кучей аргументов и условий.
Огонь. То что надо.
Приветствую Дмитрий.
Как думаете, на сколько подробно нужно расписывать евенты на этапе big pucture? Или это уже есть смысл делать на следующих этапах.
Евенты могут наступать по времени (судя по книге Альберто). Например Счёт не оплачен ещё и "Прошло 3 дня с даты выставления счёта" или "Осталось 5 дней до окончания подписки". И с одной стороны, эти евенты важны, так как они запускают команды и порождают следующие евенты - "напоминание об оплате счёта отправлено" и "напоминание об оплате отправлено". С другой стороны - этих евентов может быть так много, что они заполонят общую картину и в них затеряется весь core domain.
Плюс есть евенты, которые важные бизнесу - но они не порождают другие евенты, не запускают команды и не меняют никакую модель чтения. Реальный пример: "клиент первый раз авторизовался"
Big picture нужно делать не детально. В основном они дают понимание границ.
Например, пользователь зарегистрировался, уведомление о регистрации пользователя отправлено. По этим двум событиям уже можно понять, что тут вырисовывается два контекста: Пользователи и Уведомления. При этом в них могут быть более детальные события: имя пользователя изменено, пользователь заблокирован, уведомление удалено и т.д. Они уже важны для более детального разбора. Но они не будут интеграционными, плюс они могут быть вообще техническими только для программиста.
Обычно представители бизнеса мыслят как раз этими событиями Big picture. Тут у нас оформляется заказ, потом мы обрабатываем его менеджерами, затем отправляем на доставку, а после выдаем клиенту. Вот это и есть та нужная карта событий, чтобы понять общую картину. А уже после начинаете размещать события по времени и дополнять другие события, которые пропустили.
Если в чем-то не ответил, то можете написать. Рекомендую посмотреть на ютубе или в других источниках Баранова Сергея.
Если это просто десятки напоминаний, то их можно не рисовать. А если там уже порождается что-то более важное вроде закрытия просроченного счёта, то это уже нужно.
Если важны бизнесу, то бизнес будет на это как-то смотреть в аналитике или потом захочет использовать для запуска новых команд. Так что такие события желательно сделать и сохранять. Для аналитики по событию "клиент первый раз авторизовался" можно вписать эту дату в таблицу с датами первого входа. Это как раз будет модель чтения.
Или войти через: