Выводит намерение пользователя из потока событий в хранилище событий.Это даже правильная вещь?

Question

Мы используем хранилище событий, в котором хранится один агрегат - заказ пользователя (представьте себе заказ Amazon, который может быть обновлен в любой момент как клиентом, так и кем-либо из компании, занимающейся электронной торговлей, до того, как он действительно будет отправлен).

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

Теперь мы понимаем, что события, которые формируют совокупный корень, на самом деле не показывают намерение или то, что на самом деле сделал пользователь. Они служат только для построения текущего состояния заказа при последовательном применении к пустому заказу. Вопрос: они должны?

1. Представьте себе пользователя, у которого изначально была одна копия книги X, а затем удалили ее и снова добавили 2. Должны ли мы рассматривать это как событие «Пользователь добавил 1 книгу» или события «Пользователь удалил 1 книгу» + «Пользователь добавил 2 книги» (мы, кажется, следовали этому подходу)?

2. В некоторых случаях у нас есть одно начальное событие, за которым следуют другие события. Я, разработчик, точно знаю, что все эти события были вызваны одной командой, но мне кажется невероятно хрупким делать подобные предположения при создании на лету этой функциональности «истории заказов», которую увидит пользователь. Но если я не буду относиться к ним, по крайней мере в функции истории заказов, как к одному действию, то будет казаться, что было много изменений в заказе, когда на самом деле была только одна, большая.

Должны ли я иметь "макро" события, которые содержат "микро события" внутри? Должен ли я просто прикрепить идентификатор команды к событию, чтобы я мог легко определить, какое событие произошло в то же самое время, а какое нет (альтернативой было бы полагаться на метки времени ... но это отвратительно).

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

Спасибо

Answer 1

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

Answer 2

События (прошедшее время) не всегда отражают намерения человека или системы. Команды (императивное настроение) делают. Поскольку все данные команд не всегда могут быть легко восстановлены из событий, которые они генерировали, сохранение структурированного журнала команд выглядит здесь как хороший вариант.

Answer 3

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

Учитывая вышесказанное, я ожидал, что показ потока событий должен быть в порядке. Но я полностью понимаю, почему это может не быть идеальным в некоторых обстоятельствах. То есть это может быть слишком подробно. В этом случае, возможно, создайте модель чтения «Summeriser», которая будет кормить события.