_Перевод [статьи опубликованной на Eventsourcing Publications][1]. Статья описывает некоторые из идей примененных в проекте [Eventsourcing][2]._ Если вы читали[ статью Фаулера][3] или подобные источники на тему event sourcing, у вас в мозгу могла остаться вот приблизительно такая картинка: ![image][4] Общая идея такого подхода заключается в том, что пользователь (или любая другая внешняя система) генерирует команды, мы их обрабатываем, складывая полученные события в event store и обновляя «состояние мира» в базе данных, данные из которой запрашивает пользователь. Этот подход выглядит просто и красиво. У нас есть достаточно данных чтобы «переигрывать» события, у нас есть откуда запрашивать данные о состоянии мира и мы можем использовать проверенные временем базы данных. С другой стороны, я обратил внимание что я хотел немного другого от концепции event sourcing. Мне хотелось избежать предугадывания будущего и эта модель как-то не очень подходила, потому что мне приходилось записывать обновленное состояние в мою базу данных «для чтения». [Читать дальше →][5]

[1]: https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17
[2]: http://eventsourcing.com
[3]: http://martinfowler.com/eaaDev/EventSourcing.html
[4]: https://habrastorage.org/getpro/habr/post_images/758/f8d/8c1/758f8d8c1b3249530f9eb8ef9284efd0.png
[5]: https://habrahabr.ru/post/300956/?utm_source=habrahabr&utm_medium=rss&utm_campaign=feed_posts#habracut