Почему хранилище событий должно быть на стороне записи?
Поиск событий позиционируется как бонус за ряд вещей, например. история событий/контрольный журнал, полная и непротиворечивая регенерация представлений и т. д. Звучит здорово. Я фанат. Но это детали реализации на стороне чтения, и вы можете добиться того же, полностью переместив хранилище событий на сторону чтения в качестве другого подписчика... так почему бы и нет?
Вот некоторые мысли:
- Представления/денормализаторы сами по себе не заботятся о хранилище событий. Они просто обрабатывают события из домена.
- Перемещение хранилища событий на сторону чтения по-прежнему дает вам историю событий/аудит.
- Вы по-прежнему можете регенерировать свои представления из хранилища событий. За исключением того, что теперь это не обязательно должна быть утечка модели записи. Дайте ему прочитать образец гражданства!
Кажется, это один из технических аргументов в пользу того, чтобы оставить его на стороне записи. Это от Грега Янга по адресу http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/:
Однако существуют некоторые проблемы, связанные с использованием того, что хранит снимок текущего состояния. Самая большая проблема связана с тем, что вы представили две модели своих данных. У вас есть модель событий и модель, представляющая текущее состояние.
Что мне кажется здесь интересным, так это термин «моментальный снимок», который в последнее время также стал популярным термином в области поиска событий.Внедрение хранилища событий на стороне записи увеличивает нагрузку на загрузку агрегатов. Вы можете спорить о том, сколько накладных расходов, но, по-видимому, это предполагаемая или ожидаемая проблема, поскольку теперь существует концепция загрузки агрегатов из моментального снимка и всех событий с момента моментального снимка. Итак, теперь у нас есть... снова две модели. И не только это, но и предложения по моментальным снимкам, которые я видел, предназначены для реализации в виде утечки инфраструктуры, когда фоновый процесс проходит через все ваше хранилище данных, чтобы поддерживать производительность.
А после создания снимка события до снимка становятся на 100% бесполезными с точки зрения записи, за исключением... перестроения стороны чтения! Это кажется неправильным.
Еще одна тема, связанная с производительностью: хранение файлов. Иногда нам нужно прикрепить к сущностям большие бинарные файлы. Концептуально иногда они связаны с сущностями, но иногда они ЯВЛЯЮТСЯ сущностями. Помещение их в хранилище событий означает, что вам придется физически загружать эти данные каждый раз, когда вы загружаете объект. Это достаточно плохо, но представьте себе несколько или сотни из них в большой совокупности. Каждый ответ, который я видел, состоит в том, чтобы стиснуть зубы и передать uri в файл. Это отговорка и подрывает распределенную систему.
Потом техническое обслуживание. Для перестроения представлений требуется процесс, включающий хранилище событий. Итак, теперь каждая задача обслуживания представлений, которую вы когда-либо писали, привязывает вашу модель записи к использованию хранилища событий… навсегда.
Разве весь смысл CQRS не в том, что варианты использования моделей чтения и записи принципиально несовместимы? Так почему же мы должны размещать модели чтения на стороне записи, жертвуя гибкостью и производительностью, и снова связывать их? Зачем тратить время?
В общем, я запутался. Во всех отношениях с того места, где я сижу, хранилище событий имеет больше смысла как деталь модели чтения. Вы по-прежнему получаете множество преимуществ от хранения хранилища событий, но не слишком абстрагируете сохраняемость на стороне записи, что может снизить гибкость и производительность. И вы не связываете свою сторону чтения/записи с дырявыми абстракциями и задачами обслуживания.
Может ли кто-нибудь объяснить мне одну или несколько веских причин, чтобы оставить его на стороне записи? Или, в качестве альтернативы, почему это НЕ должно быть на стороне чтения в качестве проблемы обслуживания/отчетности? Опять же, я не ставлю под сомнение полезность магазина. Как раз там, где это должно быть :)