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

Должен ли я всегда использовать Event Sourcing?

Учитывая, что Event Sourcing находится на вершине пирамиды, вы можете сделать вывод, что вы всегда должны стремиться к вершине и использовать Event Sourcing. Стремление к высокому — благородное дело и звучит как правильное, но оказывается, что это не так просто.

Если ваше приложение относительно простое и у вас не так много предметной модели, нет особого смысла в Event Sourcing вашего хранилища данных. Например, у приложения To-Do, вероятно, нет особых причин для этого. Возможно, если вы хотите провести расширенный анализ истории элементов списка дел, в этом есть необходимость, но в большинстве случаев все, что вам нужно сделать, это сохранить несколько элементов данных в каком-либо постоянном хранилище для последующего поиска. И похоже, что уровень 1, CRUD со структурированным хранилищем, вполне подойдет, а добавление Event Sourcing только усложнит ситуацию.

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

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

Но как насчет доступа к данным?

Другой вопрос, который возник, касается используемой технологии доступа к данным. Опять же, это сложный вопрос, на который можно дать простой ответ. Это также зависит от того, смотрите ли вы на модель предметной области Event Sourced или прогнозируемую модель чтения.

Что касается источника событий, мне очень нравится GetEventStore от Грега Янга, который можно использовать как автономный сервер или встроенный клиент. Вы можете использовать HTTP API, но, поскольку я в основном использую .NET на сервере, лучше использовать собственный клиент C#.

Для прогнозируемой модели чтения это действительно зависит от того, что вы используете в качестве механизма хранения данных. В случае реляционной базы данных вы можете использовать NHibernate или Entity Framework, но это, вероятно, немного излишне и снизит производительность. В большинстве случаев вам будет лучше использовать один из ORM Mirco, например Dapper, ServiceStack.OrmLite или что-то подобное.

Хотя я предпочитаю использовать базу данных NoSQL, и мне очень нравятся RavenDB или MongoDB. В настоящее время я использую Redis с клиентом ServiceStack.Redis в примере проекта, и это также работает очень хорошо для меня.

Итак, опять же, это действительно зависит от ваших предпочтений, но выбор скорости и гибкости — это хорошо.

Наслаждаться!

Первоначально опубликовано на сайте blogs.msmvps.com 2 февраля 2015 г.