Когда впервые слышишь про Event Storming, в воображении может возникнуть ритуальный круг со стикерами вокруг доски. На деле это инструмент, который помогает вытащить из вашей системы все реальные события и понять, кто за что отвечает. А DDD задаёт логику и названия для этих событий, чтобы не плодить монстров вида «ItemCreatedButActuallyDeleted».

В чём суть?
В Event-Driven Architecture (EDA) микросервисы обмениваются событиями, а не гоняют запросы напрямую. Если забить на Event Storming и DDD, легко получить бардак из никому непонятных оповещений. Но если продумать доменные события и их связь, всё становится ясно: какой сервис что «выкрикивает» и как остальные реагируют.

Роль руководителя – не просто собрать народ у доски (реальная или виртуальная не важно), а следить, чтобы всё важное фиксировалось, и никто не увёл обсуждение в чаевые мелочи. Важно понять, как ваши события влияют на соседние сервисы и что делать, если вдруг в проде вылезло что-то типа «PaymentDoneButNotDone».

В итоге лучше потратить пару часов на «штурм стикерами», чем потом ловить хаос в логах и гадать, откуда взялись странные ивенты. Правильный подход к Event Storming, подкреплённый DDD, – залог того, что EDA будет радовать, а не сводить тебя с ума.

P.S. Частенько пренебрегаю, а потом думаю зря, в прошлый раз не воспользовался... Знаю да, а вот пользуюсь, не всегда)))

@it_underside