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

Вот смотрите:

🟧 События — это предусловия, постусловия и триггеры. (И тут как раз мы уходим от любимого всеми триггера "Пользователь нажал на кнопку" — это не событие предметной области!). Почему предусловия и постусловия — это события? Потому что событие в ES — это что-то, что случилось в прошлом и уже неизменно. То есть, вообще говоря, это состояния каких-то объектов предметной области, или в терминах ES — агрегатов. В этом смысле поток событий можно и как диаграмму состояний трактовать.

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

🟦 Команды — это шаги юскейса или целиком юскейсы, смотря на каком уровне мы смотрим. Тут, кстати, тоже снимается вопрос, который часто возникает при проектировании сценария юскейса: прерывание выполнения. Юскейс — это цель, которой пользователь может добиться за один сеанс работы с системой. Может ли он посреди этого сеанса встать и уйти? Или наоборот, должен ли ждать завершения выполнения какого-то действия? В случае юскейсов обычно этим пренебрегают, т.к. число юскейсов начинает кратно расти. А ES заставляет задуматься о каждом переходе между действиями (командами) — он синхронный или асинхронный? Достигли ли мы какого-то состояния, в котором можем находиться сколь угодно долго, или это состояние должно сброситься через определенное время?

Это связано и со stateful/stateless — следим мы за состоянием или нет. REST предлагает за состоянием не следить, то есть мы можем положить товар в корзину, а потом через день положить другой, и это норм. Но это значит, что у нас нет юскейса "сформировать корзину", есть только "добавить товар в корзину" и "оформить заказ", и это разные кейсы. (Кейса "сформировать корзину" нет ещё и потому, что нет такого события "корзина сформирована")

Интересно, что в обратную сторону это не работает — шаги юскейса могут быть не командами, а инвариантами-проверками внутри 🟨 агрегата (вот эти вот шаги "система убеждается") или 🟩 моделью чтения ("система отображает").

А 🟪 полиси — это либо триггеры, либо точки ответвления для альтернативных сценариев.

Тут получается, что ES диктует размещение бизнес-логики в разных местах: внутри агрегатов (инварианты) — то, чего никогда не должно случиться (предотвращение событий), и в полиси — как реагировать на то, что уже случилось (реакция на события).

Акторы, они везде акторы (хотя в ES — и 🟥 системы тоже).

Остаются только UI, но это тоже понятно — мы и в юскейсах можем спросить, на каком экране происходит этот шаг сценария и как это выглядит.

Так что ES — это те же юскейсы, только записанные необычным образом и с указанием объектов данных (агрегатов). Но! В моделировании юскейсов нет инструментов для выявления ограниченных контекстов и поддоменов.

Ну вот как вы будете выявлять их? Через CRUD над объектами? Через что? Нет механизма. В Use Cases 2.0 (и 3.0) появляются слайсы, но это скорее элемент управления работами. Если методика ещё получит развитие, где-нибудь в Use Cases 4.0 или 5.0 увидим что-то для выделения контекстов.