Вступление

По мере того как проектирование и написание кода переходит к ИИ, разработчику всё реже нужно глубоко разбираться в том, как устроена система, и всё чаще достаточно описать, что она должна делать. Обычный разговорный язык для этого не подходит, поскольку допускает множество интерпретаций, поэтому нужен язык, близкий к естественному, но достаточно однозначный, чтобы ИИ мог преобразовать описание в работающую систему. Такой язык опирается на концептуальную модель, то есть на набор понятий, с помощью которых описывается бизнес. Чем естественнее эти понятия отражают бизнес-логику и чем проще воплотить её в коде, тем лучше модель. На наш взгляд, событийная модель хорошо отвечает этим требованиям, поскольку позволяет описывать бизнес через свершившиеся факты и процессы (а не через сущности и их связи), а Event Sourcing (ES) даёт архитектурную основу для её реализации.

В качестве «языка программирования», основанного на этой модели, могут служить диаграммы Event Storming, Event Modeling и родственных им подходов. Очевидно, что такой язык не содержит, да и не должен содержать, никаких инфраструктурных механизмов, таких как диспетчеризация, публикация, запуск обработчиков и т. п. Это означает, что ИИ придётся проектировать их каждый раз заново, что, в свою очередь, будет приводить к ошибкам. Чтобы избежать этого, помимо языка нужен ещё и фреймворк, который возьмёт на себя типовые механизмы и оставит ИИ только то, что специфично для конкретной системы: бизнес-логику, подключения к внешним сервисам, репозитории, запросы, проекции и т.п. Для Event Sourcing таким фреймворком может быть, например, Axon.

Цель данных публикаций — дать целостное понимание концептуальной модели, на базе которой построена архитектура ES, а также на ряде примеров показать, как можно решать те или иные задачи с помощью диаграмм Event Storming/Modeling.