Why use Event Sourcing?

Уди и я соглашаемся, вероятно, на 95% того, о чем мы говорим, одно из мест, в которых мы имеем разные мнения, заключается в использовании Event Sourcing. Я использую термин, описанный ранее, как означающий перестройку объектов на основе событий, а не определение который в настоящее время находится на блики. Для меня это важное различие, и я подумал, что было бы полезно написать сообщение о том, почему я так себя чувствую, я объяснил его части в предыдущем посте о CQRS и Event Sourcing, но я хотел поговорить не только о том, как шаблоны симбиотические, но также и некоторые другие причины, по которым я использую источники событий.

Использование СУБД

Для начала рассмотрим альтернативную архитектуру, то есть перестроить объекты из того, что сохраняет текущее состояние на стороне записи. Я говорю что-то, потому что это может быть много; bigtable, mongodb, реляционная база данных, xml-файлы, фотографии объектов, которые затем сканируются … На самом деле это не важно для обсуждения, важно хранить текущее состояние. Для обсуждения давайте представим себе, что это реляционная база данных, которую обычно рекомендует Udi здесь — это слайд, который он обычно использует, чтобы говорить об этом.

Данные хранятся, как обычно, в реляционной базе данных, и домен также предназначен для отправки событий, которые затем могут использоваться с моделью чтения. Есть некоторые действительно хорошие вещи об этой архитектуре, которые я хотел бы пройти, прежде чем я расскажу о некоторых проблемах, с которыми я столкнулся с ним в прошлом.

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

Однако есть некоторые проблемы, связанные с использованием того, что хранит моментальный снимок текущего состояния. Самая большая проблема связана с тем, что вы представили две модели для своих данных. У вас есть модель события и модель, представляющая текущее состояние. Если вы посмотрите на приведенную выше диаграмму, вы увидите, что есть две операции, запись и публикация.

Каждый раз, когда вы представляете вещи более чем в одной модели, вам приходится беспокоиться о том, чтобы синхронизировать эти две модели, и эта ситуация не исчезает. В качестве примера, как вы рационализируете, что данные, которые вы сохранили в своей базе данных, действительно совпадают с событиями, которые вы отправили? Можно написать единичные тесты, чтобы помочь синхронизировать ситуацию, но в конечном итоге они не синхронизируются друг с другом, и когда это произойдет, у вас возникнет проблема.

Еще одна проблема с наличием двух моделей заключается в том, что это обязательно большая работа. Нужно создать код для сохранения текущего состояния объектов, и нужно написать код для генерации и публикации событий. Независимо от того, как это делать, это не может быть проще, чем только публикация событий, даже если у вас есть что-то, что сделало сохранение текущего состояния совершенно тривиальным, чтобы сказать хранилище документов, все еще есть усилия, связанные с его внедрением в проект.

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

Использование Event Sourcing

Использование Event Sourcing не меняет архитектуру выше, основное отличие заключается в том, что у нас есть хранилище событий, в котором хранятся события, чтобы перестроить объект за доменом, а не что-то, хранящее текущее состояние. Однако существует много интересных различий между этими двумя архитектурами.

Первым важным отличием является то, что он решает проблему наличия двух моделей. Он устраняет затраты на то, чтобы иметь дело с синхронизацией между ними, и, что самое важное, он устраняет возможность того, что эти два расходятся. Различия моделей могут быть очень плохими, поскольку мы используем модель событий в качестве нашей модели интеграции, чтобы другие могли создавать параллельные модели нашей модели. Если у нас возникнет проблема синхронизации, у них будут плохие данные, тогда как у нас есть правильные данные, ouch. С Event Sourcing мы сохраняем событие (которое можно даже назвать «публикацией»)

Однако есть и другие преимущества использования Event Sourcing, а не сохранения текущего состояния. Некоторое время я проходил через некоторые из них в другом посте. Одно из преимуществ заключается в том, что мы можем избежать необходимости использовать транзакцию 2pc между моделью данных и очередью сообщений (если мы ее используем) … причина в том, что сама память событий также является очередью, мы могли бы отставать хранилище событий, чтобы поместить элементы в очередь (или напрямую использовать хранилище событий в качестве очереди).

Тестирование, однако, является большой победой в Event Sourcing, так как все ваши изменения состояния выполняются через события, вы можете просто проверить события, выходящие с другой стороны. Это особенно интересно, если учесть, что с событиями, поскольку вы четко указываете, что меняется, вы также проверяете, чего не происходит . Очень немногие люди пишут тесты, чтобы показать, что не происходит по поведению (также основное место, где модели могут потерять синхронизацию), например: я звоню на ScheduleAppointment на объект, проверяете ли вы, чтобы адрес не изменился? Так как я в тестировании утверждал, что получил только AppointmentScheduledEvent. Помимо этого, поскольку мы толькоиметь дело с событиями с другой стороны, мы можем рассматривать (и тестировать) наш домен как довольно сложный конечный автомат, который предлагает некоторые очень интересные возможности.

Конечно, мы оставили в стороне то, что, по моему мнению, является одним из ключевых значений Event Sourcing, у нас действительно есть изменения. Предположим, что я получил нарушение параллелизма (запрос от версии 5, а текущие данные — в версии 12). С помощью Event Sourcing я могу запросить все эти события между ними и посмотреть, действительно ли кто-то из них конфликтует с командой, которую я хочу запустить (в ближайшее время я напишу сообщение об этом подробнее). Другими словами, мы обеспечиваем интеллектуальное слияние …

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

Надеюсь, это немного объясняет различия между моделями. Я хочу предоставить людям также быстрый список некоторых плюсов и минусов каждого.

Current State Backing

Pros

Легче модифицировать устаревший проект

Хорошо известные технологии / инструменты / наборы навыков

Легче продать организации

Cons

Двойные модели стоят дороже и содержат риск

Неофициальный центр

Event Storage Backing

Pros

Единая центральная модель события

Упрощенное / лучшее тестирование

Управление конфликтами

Cons

Сложнее продать организации

Менее известные инструменты / технологии (хотя вы можете реализовать хранилище событий в РСУБД, который смягчает это)

Очень сложно перенести на устаревшее приложение.

===

Original(English): http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/

Translation: Basic, need improvement

Status: Draft

Action: Vote to improve