Я читаю на источники событий и у меня есть вопрос относительно настойчивости.
Я все еще могу иметь БД со всеми сущностями, верно? Или события должны воспроизводиться при каждом запуске приложения, чтобы получить последнюю версию каждого объекта в памяти? Похоже на отходы в больших системах (как в большом количестве данных)?
Смысл с источником событий в том, что я могу воспроизвести события, чтобы заполнить хранилище данных, если это необходимо? (или проанализировать данные)
Ответы:
Вы извлечете максимальную пользу из источников событий, когда решите также изменить архитектуру своей системы. Переход к архитектуре в стиле CQRS в сочетании с DDD принесет истинные преимущества источников событий, по крайней мере, на мой взгляд.
Создание хранилища событий, которое ведет себя хорошо в больших системах, на самом деле не простая задача. Воспроизведение всех данных может быть действительно дорогим, во многом зависит от объема данных, которые необходимо воспроизвести. Но есть методы, которые могут помочь вам в этом, одним из которых является концепция снимка. Повтор производится только с определенного момента. Преимущества, которые магазин событий приносит в вашу систему, неоценимы. Благодаря тому, что все, что происходило в вашей системе, воспроизводилось, все данные в любой момент - это здорово. Подумайте об анализе, о воспроизведении ошибок, о статистике.
Есть много больших магазинов событий, последняя была выпущена только вчера Event магазин и, похоже , действительно хороший.
Традиционная база данных может быть сохранена для части запроса вашей системы для создания DTO с запрошенными данными. Эта база данных может быть организована и оптимизирована с учетом потребностей запросов вашего приложения и клиентов.
Я написал подробную статью о том, каковы преимущества и как на самом деле выглядит архитектура CQRS в сочетании с источником событий. Вы можете проверить это CQRS, доменные события и обзор DDD .
В Event Sourcing главный вопрос: «Какая у вас книга рекордов».
Если ваша книга рекордов - это ваш поток событий, у вас не будет проблем. Если ваша книга записей - это ваша «модель сущностей», тогда проблемы начнут возникать повсюду. Частично это то, что вы можете сказать: «Если бы я потерял свою модель сущности, я мог бы перестроить ее из своего потока событий». Если вы уверены в этом вопросе, то ваш журнал событий - это ваша книга рекордов.
Также важно помнить, что большинство людей, использующих источники событий, используют модель чтения. Эта модель используется для запроса данных. Впрочем, это скорее похоже на модель с 1nf, чем на 3nf. Они только воспроизводят события, чтобы вернуть состояния агрегатов, чтобы определить, следует ли разрешить запись.
Я все еще могу иметь БД со всеми сущностями, верно? Или события должны воспроизводиться при каждом запуске приложения, чтобы получить последнюю версию каждого объекта в памяти?
Ответ зависит от требований вашего приложения. Я видел, как это делается в обоих направлениях.
Один чрезвычайно успешный программный пакет для небольших бухгалтерских фирм читает журнал CQRS каждый раз при запуске. Объем необработанных данных был относительно небольшим, поэтому время запуска было меньше минуты даже на медленных компьютерах. Они занимались CQRS более десяти лет, прежде чем практика стала популярной. Они знали, что добились чего-то хорошего, когда поняли, что могут снова и снова обновлять данные своих клиентов, не сталкиваясь с проблемами, которые они видят в своих более крупных системах.
В системах с большими объемами данных и / или системах, которые полагаются на функциональные возможности СУБД для реализации стороны запроса, у вас есть база данных для «текущего представления» данных, полученных из событий (вы даже можете иметь несколько таких представлений). Преимущество этого подхода состоит в том, что он позволяет вам строить запросы с использованием знакомых технологий.