Когда использовать EventStore

Ответ 1

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

Я согласен с Крейгом в том, что трудно ответить на ваш вопрос лаконично, потому что он очень зависим от контекста, но вот краткий список причин, по которым вы можете использовать хранилище событий:

• Вы заботитесь о сложном историческом анализе своих данных. Например, кто-то может прийти к вам в будущем и спросить: "Сколько наших клиентов положили товар в свою корзину покупок, а затем вытащили его, но после того, как мы отправили им купон, вернулись и купили его?" Там может быть бесконечное предложение таких вопросов BI, и вы не можете заранее предугадать их всех. Если вы фиксируете все события в системе, вы можете восстановить ответ на любой будущий вопрос.
• Точно так же вы заботитесь об аудите и можете безоговорочно доказать, кто изменил какие данные в какое время и почему. Ваш журнал событий - это ваш журнал аудита.
• Вы заботитесь о наличии высокомасштабируемой системы. Так как модель записи хранилища событий является только append, она может быть хорошо подходит для приложений большого объема. Поскольку он не является неотъемлемо реляционным, его обычно можно легко разделить.

С другой стороны, есть веские причины не делать этого:

• У вас нет каких-либо требований, перечисленных выше.
• Вы не хотите иметь дело с необходимостью создавать инструменты для отладки, чтобы иметь возможность легко просматривать и изменять данные в хранилище событий.
• Вы строите недолговечный проект, который вы не ожидаете находиться в течение долгого времени, поэтому не хотите вкладывать в него массу усилий по архитектуре.
• Вы не готовы изучать CQRS, DDD и EDA одновременно с поиском источников событий. Эти идеи не являются строго обязательными для источников событий, но они часто переплетаются, и истинное значение обнаруживается, когда вы полностью меняете свою парадигму и используете их все вместе. Событие sourcing является частью пакета методов, которые вместе представляют собой совсем другой образ мышления о архитектуре программного обеспечения. Это может быть пугающим.

Ответ 2

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

Грег Янг: Существует ~ 2-часовое видео здесь, которое дает отличный обзор всего, что вы просите в своем вопросе. Существует также ~ 6-часовой онлайн-класс здесь.

Уди Дахан: Существует 1 час видео здесь, в котором дается представление о том, когда использовать эти технологии.

Список рассылки: Здесь есть группа здесь, где вы можете задать все ваши вопросы и провести приятное обсуждение темы.

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

Обновление: я не думаю, что вам нужно читать 5 книг или даже просматривать видео ниже. Я думаю, что это стоит того, чтобы сделать это, но не обязательно. Проблема с вашим вопросом заключается в том, что для "простых" сценариев обычно не требуется получение источников событий. Большинство приложений будут в основном CRUD и управляться данными. Возможно, это ответ на ваш вопрос. Если в вашей системе не так много "поведения", вам это не нужно. Если есть много поведения, тогда вам может понадобиться.